I can only reproduce this by setting the Differential application to a restrictive policy such as administrators only. With default policy, uninstalling the Differential application does not reproduce this. Updated the task.

I peeped the IRC log so I'll take a stab at this now.

Closed by commit rP9141da84c85c.

At least for now, this no longer blocks Phacility or T2783.

Closed by commit rP2b99b4add8ae.

T2783 is at least partially blocked on this, since I need to make intra-cluster calls as the viewing user and don't want to do handshakes. I also don't really want to ship session keys across in the raw, although that wouldn't be the end of the world. I'll probably push this about halfway forward and then drop it again once T2783 is unblocked.

There's still some cruft in the codebase here. Mainly the transaction rendering code for the old style transactions. I have to (maybe) fix something similar for projects so if this doesn't look ridiculously bad I'll fix this bit too.

Oh, I thought this was about the global search. The existing patch only covers the global search in the upper right.

I can reproduce it on the WMF install in tokenizers:

When I type "Wikidata" on your install its the top result:

Wikimedia upgraded yesterday, and while typing "Wikidata" seems to bring "Wikidata" among the top five suggestions, it is not the top result, which makes us think that we can still run into scenarios like the one described here.

Closed by commit rP7d9687057056.

The problem went away as soon as I updated.

Should be fixed in HEAD. Thanks for the report, @chasemp!

Closed by commit rP5b59a81ab9b3.

thx @btrahan

Well, maybe I'm wrong. I can't reproduce this with other account types. For example, I have no option to attach a second Facebook account:

In particular, this is very unlikely to be particular to Mediawiki, and should reproduce with other providers (like GitHub). (If it doesn't, there's just an issue we need to fix with the MW adapter.)

Oh cool. I've updated and will report back.

I'm actually not seeing this issue any more after updating.

Support Impact I haven't triaged, but this looks like a bug with no recourse.

I haven't triaged this but it sounds like it may have Support Impact.

Support Impact This breaks things and users have no recourse other than reporting it.

Expected behavior is that this is prevented until T2549, which will eventually make this work properly.

For what is worth, this problem caused confusion among users that were ignoring "updated subscribers" notifications but still could see them in their feeds. It took us a while to realize that these notifications were legit, just misnamed: https://phabricator.wikimedia.org/T76098

Phacility part of this seems to be holding, we don't need to address phabricator.com as a launch item.

Well, maybe not that messy. I think I got away with at least one of these pretty cleanly in the past, since you basically just copy the table into the edge table and theoretically you're about done.

Should be good to go, this just involves a messy migration.

Stealing this from you to do these bits...?

Another one I figure I should do unless you've got something... Lemme know!

In T5245#68198, @epriestley wrote:

This is mostly complete, but:

• Maniphest should implement PhabricatorProjectInterface, but picks up two "Projects" fields in the UI if it does. Its projects field currently shows board columns, so we can't just delete that copy. After T4807, we can generalize this and implement PhabricatorProjectInterface.
• It would be nice to migrate old TYPE_PROJECTS transactions to TYPE_EDGE transactions to remove leftover rendering code.

I'm currently making the Phacility deployment tools load all Almanac services and filter them on the client to generate a list of instances hosted on a given machine (e.g., all instances with storage on db001). This is super gross:

Closed by commit rP798be00fc3c7.

I think adding is desirable. We never rewrite history anywhere else.

Is the desired behavior that

As usual, reasonable and clear. Thanks man.

@chasemp and I talked about this some more on IRC. We still don't have exactly the same viewpoint on where we should end up, but I think we can take an approach which everyone's onboard with for as long as possible and then possibly deviate a little at the end. Broadly, I want to implement the parts of this which would lock down or restrict capabilities first. Once we've implemented the heaviest set of restrictions, we can evaluate what holes we want to punch through them based on user feedback.

While digging in there, it looks like having coverage information as a per-test datum is not actually the common practice in any test framework - in all implementations I saw, it's generated separately and just pasted into each test.
Maybe we should have it as a separate field in the diff data too?

D10895 appears to be a sufficient fix. I want to adjust some other keys on this table eventually so I'm going to leave this open, but I'll downgrade the priority once the dust settles.

All realistic installs with more than 100K rows should have 99% of them in queue.

I think these are done: