We have the same issue after the last update and we usually update once a week. I can confirm that the issue happens with any commit to a SVN repository that you want to view via Audit. Git commits display fine.
Might this be related to the change "Old", "New" and "Diff" tabs in the web UI from your latest changelog?

See Restarting Phabricator for detailed instructions on how to restart Phabricator after an upgrade.

Hit by the exact same issue of Unknown column 'event.dateFrom' in 'order clause', and arrived here through search. In hope this helps somebody else, here's how I fixed it.

I think that will prevent these edits from occurring by accident via the web UI. Yell if you manage to trick it or it causes any weird stuff.

This is way outside the realm of an upstreamable bug report with reproduction steps, but run this again:

Here's the raw data from that install:

Dragging a card on a workboard while in a priority-ordered view changes the global priority (see T8135). Mail tags in "other" groups are arbitrary, unclear, and going away (see T10448). I'm going to merge this into T10448.

I was able to reproduce in this test instance. There is a parent project called Parent, and two subprojects: Sub1 and Sub2. Sub2 produces the error.

Sounds similar to T10779

I can't reproduce this. Can you create a test instance in Phacility and reproduce this there?

Versions:

• phabricator 111c63955155046bbd57c3836c78d460ebe13dfb (Sat, Nov 5)
• arcanist e17fe43ca3fe6dc6dd0b5ce056f56310ea1d3d51 (Fri, Oct 21)
• phutil 40e473e057885dab5de4fb42901f7fff2d340a6a (Sat, Nov 5)

Thanks for that confirmation. I like the look of your code comment: "Possibly we should white-list this kind of mail and deny all other types of mail." I'll create an enhancement request task related to that.

is Phab supposed to send email to users who are unverified?

Re scenario 1, I found another way to investigate it rather than digging up old logs. Question, though: is Phab supposed to send email to users who are unverified? Looking at mail logs, it seems one of our most recently added users was sent quite a lot of mail, perhaps all mail they would ordinarily get, prior to verification. If Phab is supposed to send mail to unverified users, then this would be an enhancement request which I could submit with a proper description of the use case. If not, I can investigate how to reproduce the behaviour.

Most of the work is disk/DB bound, so not having a high cpu load makes sense. That said, processing a lot of tasks will take a while.
When a task fails in an unexpected way, the daemon thread backs-off for a while, so it takes much longer to fail a task than to complete it; Unless most of the commits are failing, it should speed up at some point.
These tasks are also lower-priority than Herald and Publish tasks, which is why those get executed before these; Once these tasks are out of the queue, expect work to happen faster on the commit parsing tasks.

First, thank you for taking the time to answer...

Are the daemons doing anything? Are any tasks, at all, getting done? Are some tasks failing?

Sorry, I should have been more clear..

./bin/phd start will start all the right daemons. Look in the Daemons app in the web interface to see what's going on.

Nope, phd is definitely *not* making any progress on the PhabricatorRepositoryGitCommitMessageParserWorker queued tasks I'm stumped. When I run this:

Yes.. interesting, I had not considered that. I'll re-activate the repo

are the daemons running? You might need to activate the repository for the commits to be parsed.

One other thing that I should note, these commits are all in a repository that is no longer active. (if that matters)

OK, Here's the issue (from what I can tell)
PhabricatorRepositoryGitCommitMessageParserWorker has a count of 105,000 in the queue, but for some reason those commits are not getting parsed. I don't want to 're-queue' them by removing the --force-local, because (according to the help) that will duplicate the work that is already queued. How can I get phd to start working on those commits?

Will try.. Thank you.

I believe that if you drop --force-local, the reparse code will schedule the reparse to run using the daemons, which should fail to parse this commit and continue to the next one.

The task for parsing this commit should auto-cancel because it encountered a PhabricatorWorkerPermanentFailureException. In this case, you're manually re-parsing it, but it shouldn't be happening automatically.

What can I do next to get the commit parser to stop trying to parse this.

Related thought: I wonder how the sticky task order fares when a task is on multiple workboards; since the subpriority seems to be a task parameter, not a workboard card parameter, I guess moving it on one workboard may clobber its position on another; quite possibly not a problem in practice.

What's unclear?

Hmm yeah, we record where in the workboard card is in the list, sticky. We could probably ignore that transaction.

OK. The type of the other transaction is subpriority. From the database:

Initialisation doesn't seem to fit the pattern, as I would have expected an earlier column change to trigger it if that would. There are also over a dozen transactions on the timeline of this task before the section I pasted here, including comments (one deleted; I wonder if that's relevant), column changes, reassignments, and status changes.

There might be some crazy edge case of empty custom field that was previously hidden in a custom form and is being initialized for the first time, but not generating a visible transaction, so is getting lumped under "other". Hard to say, I can't really recreate how this might happen. Do you have "other" email sent to "on" but everything else "off" ? Knowing those would be important in a reproduction case as well.

Yes, both. I don't see how either of those could be involved with a column change, though, could it? Changes to our custom field do show on the timeline, too, but nothing is showing here.

Do you have custom fields or custom forms?

I wouldn't call this resolved. Invalid may be most relevant, as with no STR, we can't confirm or action this.

{auto-playing-audio WilhelmScream.mp3}

Welcome to the wonderful, spooky world of Quicksand.

Yes I did have the persistent chat pane open. Also can't seem to repro without it.

Quicksand

Do you have the persistent chat pane open?

The other errors that appear in DarkConsole:

D16837 should clean this up. Thanks for the thorough report!

Just had this issue today on our mercurial repository. Exact same exception when executing ./bin/repository update --trace <repository>
I've managed to solve it.

ah, seems like a restart of apache fixed it.

(Please ask general admin questions like this in Ponder).

We unfortunately do not take installation questions as bug reports. We're happy to assist with our Phacility Consulting if you need or use Support Resources.

In the phabricator directory, what does file bin/config say?

I'm happy to change this if anyone comes up with good alternate wording, but I think this might be about the best we can do.

whew! good to hear.

Definitely there was a problem with the installation, for some reason the files got corrupted and downloading a fresh installation solved the problem.

Thanks chad. I will check if there is a problem with the installation and let you know.