Thanks for the analysis and the change. It makes a lot of sense to me now and, to be fair, I wouldn't have even seen the exception had the repository finished importing, which is what the fix does.
Thanks again.

Ahh, yeah D16234 was it. I'll make sure to update to HEAD next time. Thanks guys.

D16271 probably either fixes or moots this.

I can't really reproduce this, exactly, I think (?), but I suspect I can fix this and T8124 by just making this code simpler.

Please update Phabricator and re-test. We require bug reports be made at HEAD.

(This doesn't do anything bad, just spams the logs a bit, so no rush to update.)

Update past D16234 (July 5).

In T11307#185338, @epriestley wrote:

T10907 is also sort of adjacent.

T10907 is also sort of adjacent.

When moving a repository from "importing" to "imported", we check if any commits are marked as still needing to import.

The above analysis is correct.

Just encountered the same problem :(

Since it was super late and I should go to bed i decided i should try and figure out what it means.

You must include reproduction steps when filing bug reports. See Contributing Bug Reports.

Oh wow! Thanks for looking at this on a Sunday morning!
If this is expected then I think there are a couple of things that are happening that could make it better:

1. It looks like an uncaught exception, which seems like a crash and definitely says "unexpected"
2. It gives no explanation of what's really going on here. All there is is Commit "191140" has been deleted: it is no longer reachable from any ref., but it's unclear what 191140 is, and it doesn't look like a valid commit, so at a glance, it looks like something isn't getting parsed right. It is also happening while parsing a commit that I can't find in my local copy, but it exists in Phabricator's local copy. An explanation on how that could happen would be useful, too.
3. Most importantly, it gives no way to get out of this state. There are now commits stuck in "Importing" state permanently, which leaves the entire repository in an unfinished state. Providing the user with a facility to resolve this (and pointing them to it in the error message) would go a long way here, even if it's something simple and brute force, like ignoring this commit, or marking the whole repository as imported (which is what I ended up doing).

I deployed that stuff to the affected shard and things look OK now. The original issue described in this task wasn't affected.

This didn't really end up being related to the other issue here (streaming huge diffs into Files) but it's a little late for me to split it out now.

parsing probably shouldn't crash

This is largely the result of --find-copies-harder being explosively slow for large result sets in large repositories. With this flag, the runtime rises from <1s to >3m, at which point git itself bails out:

This is actually happening on the cluster/daemon pathway so it's not really related to the original issue here. However, the daemon client is timing out:

I suspended the instance in question since it was a test instance, and continuing to generate web requests for the 5M-line diff and disrupt other processes on the shard.

We had a shard disruption in the cluster this morning that I don't have a clear smoking gun on, but one issue that looks questionable is on this pathway -- I see several requests to generate diffs of an extremely large (5M line) commit coming from the web.

Yeah, T8124 is definitely the error user-facing I saw when this occurred, except there's no possible way to edit your profile pic at that point as the exception takes up the whole page.

I think it would be better not to fallback at all and raise a setup warning. We'll likely have other issues in the future for not using the native driver.

T8124 is probably adjacent.

What I found interesting about this bug is, I've had some obvious high latency with this storage engine - but incremental storage uploads for large files work fantastic in every use case I've tried, e.g. cancelling requests and all kinds of stuff. I guess this 'magical' default profile picture creation can't use the 'resume upload' mechanics?

(I made about six typos in the original version of that comment, so reload if you're following the steps from email.)

It's possible that we're in the wrong by falling back to set character set utf8;.

impressive

@eadler, I was just able to resolve this on our installation by installing the php56w-mysqlnd package instead of php56w-mysql, which is what we had installed before.

thanks, I couldn't seem to find it.

doesn't reproduce anymore

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!

I have not heard any issues from uses since we deployed this fix so I would assume it is resolved as well. Thank you!

there's actually unitests here!

Everyone got to learn something new about Git today!

yeah, I just need to build the right test case...

D16149 has this code:

if ($tag_type == 'tag') {
  $this->log(pht('Skipping, this is a tag of a tag.'));
  continue;
}

Maybe the right thing to do is to check for != 'commit' instead?

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.

Whatever string this is:

Here are the results of that command:

(The harbormaster_object table is just a test table used by unit tests.)

You could also try running these commands against MySQL:

You can likely reproduce the issue in a repeatable way with this 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.

Seems like that commit imported fine.

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

Sounds like this is resolved for now. Feel free to file a followup report if you are able to identify reproduction steps.

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

I can't reproduce this. Bug reports MUST have reproduction steps.

That's not expected and I can't reproduce it.

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

D16259 should fix the autocompleter on German layouts.

T11263 may be related here.

Presuming this was resolved by D16095 since we haven't seen further reports, or new reports of brokenness.