All files from before you upgrade to D16270 are haunted and subject to ghastly behavior.

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.

I just wanted to add a vote of support for this (following up from here) - for Haskell.org Windows is one of the "Tier-1" platforms that we ship binaries for, and having continuous integration is exceedingly useful for a number of reasons.

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

Can you update this ticket after reading this wiki please. It will save time for both you and the upstream.

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.

Specifically, we're happy to take feature requests that state a core problem a user is having using Phabricator. I don't see any core problem in this request and I can't really come up with any problems integrating Facebook at Work solves that installs can't resolve in other ways. I can't even really understand what "integrate them" means, exactly. Just authentication? I don't see where they offer anything else and in order for us to dedicate time to something, we need to expect a portion of our installs to adopt that feature.

See Contributing Feature Requests for how to file a feature request.

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.

You can still create limitless rooms with titles with 1 other participant. I just want a means of messaging one person in a persistent place without a room title. It's definitely a bit cumbersome to just send 1 person a quick note.

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

I'm with @epriestley on this - on our install I too have multiple discussions with same individuals, discussing different topics :) It keeps things clear.

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

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 in any mobile browser (Safari, Chrome) I have access to. Presume resolved, but if still occurring please re-open with full reproduction steps.

Prose diffs have resolved this.

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.

Why so aggressive ? There should be an option to ignore warning since some users already run Phabricator in PHP7 environment. Such as :

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.