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.

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

I have same problem with http

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!

Aw, shucks :)

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

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.

I can imagine an odd coverage reporter that chooses not to generate reports for files without any coverage. This might not be a real thing though.

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.