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

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

Update past D16234 (July 5).

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.

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

(We don't need to require a room name, and I think that's only a skin-deep UI requirement and not actually enforced lower down in the code.)

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.

At least personally, I don't think this is weird -- I think of it like sending email.

T8124 is probably adjacent.

(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;.

That option is "comment out the check", as @khanhicetea has done in T9640#184512. Phabricator is open source, and you are free to modify it.

I believe there's no actual issue here outside of the RSVP/instancing issue and other issues resolved or tracked elsewhere. If there is, file a new report -- with reproduction steps -- after Calendar leaves prototype.

(Only unique queries are saved, so this should be a small amount of data in most cases, but the Phacility setup tends to mean we issue a lot of unique queries.)

Using an extended policy sort of fixes this, except that extended policies currently only strengthen policies, so I also have to weaken the default View policy. This potentially makes the UI misleading, since it suggests that "all users" can view an instance, which isn't true.

One possible approach is to cache policy checks (when we've determined that user X can see object Y, cache that for the remainder of the request), but I don't want to do this idly since it has far-reaching implications, and there are cases where this cache could potentially produce the wrong result (for example, when we predict the effects of making a policy change during an edit, we evaluate objects as though they had a different policy than they really have).

Everyone got to learn something new about Git today!

Whatever string this is:

(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:

Seems like that commit imported fine.

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

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

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

I'm going to merge this into T10252, which may not be the same issue, but which has reproduction steps.

D16259 should fix the autocompleter on German layouts.

T11263 may be related here.

(My guess is that 95% of the time the engine can just match all ".js" or ".php" or ".c" or ".m/.mm/.swift" files and get the right result without requiring configuration.)

My inclination is to implement something like this:

This is reasonable, but should wait for T5568, which probably needs T5055.

Presuming resolved based on followup issues and stargazing.

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

This is purely hypothetical and it's hard for me to imagine users getting it wrong by accident.

After D16226, panels no longer support tagging.

This is working as intended.

We might have had some kind of dialog action from lightboxes in the past (or planned to have one -- like image inline comments?), but didn't have a lightbox action from dialogs until inline previews.

This was fixed by D16238 (Tuesday, July 5). It's available at HEAD of master and will promote to stable and be available in the Phacility cluster in a little more than 24 hours.

This is enormously complex to implement in the general case.

A possible fix to this is to handle ` on keydown instead of keypress (as we do for some other other keystrokes) but since we can't reproduce it we can't test that.

Your database may not have proper column encodings configured. Run this command to verify them:

D16253 should fix this; a quasi-workaround in the meantime is to set "Short Names" on repositories.

(Or likewise with the task ID.)