Thank you for the response, it is very likely a dup of T9898

More detail:

It's not 'Hanging', it just doesn't appear to be doing with queued tasks and this is the output (repeated ad nauseam)

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

Sorry, I should have been more clear..

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

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.

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

I'm curious, is there any other way to trigger Herald to process a Differential review *other* than uploading a new diff?

Yes! Thank you.. that's it, closing this question.

Yes, nothing is in the transcript, in other words, no job was triggered

no.. they've been a part of that project since the beginning

yes... they're secret :)

Thanks for the response, it does seem D15958 is what I am looking for.

I'm thinking the problem with our DB can be fixed by this:
https://mathiasbynens.be/notes/mysql-utf8mb4

In T11291#185026, @eadler wrote:

We're seeing an identical issue on our install. What version of MySQL are you using? Maybe we can work together and figure out how to get Emoji to work!

it's definitely the 🎪 that's causing the issue, not the redacted bit. I think it's an issue with our DB, but ./storage status thinks it's fine.

Here are the results of that command:

Unfortunately, the repo is confidential source, we might be on our own to debug this one. Perhaps there are issues with our database configuration @edibiase might have more info.

./storage adjust returned no errors. Pushing to the GITTEST repo gave me the following error:

got it.. if I can figure out how, I'll let you know, in the mean time, cancelling the task has kept it from happening again

Task ID is the same - for the record, I canceled the task using phabricator/bin/worker

Correction, not hanging, but continuously re-scheduling that task in the queue (which is slowing up the queue significantly)

Follow up question, this task has failed 38022 times.. is there some way I can punt it from our queue?

OK, Feature request filed here: T11158

Any way to bump the priority of this up?