Leftover Raw Members

Repeatable read is required if statement based replication is used - if row replication is used - repeatable read is no longer a requirement for replication consistency...

This at least resolved the obvious badness in the case of PHI1979.

However, the existence of the original code might point at a bug in the "Variable Reused as Iterator" lint check: I would expect it to have prevented the original code in the first place.

As a coarse first pass at this, forcing the commit cache to fail results in a full discovery of the Linux repository in 14 seconds, versus 2m36s with normal cache behavior.

I updated the description, but the relevant workflow is during the "discovery" step, not the "refs" step. The "refs" step uses the RefCursor table and doesn't interact with the commit cache.

It looks like the case in PHI1977 was actually a situation of attempting to trigger an audit by writing a Differential rule, so the Global/Personal stuff may still be worth fixing but has zero known cases of actual confusion in the wild. I'm less sure how the UI could be clarified around the Audit/Differential issue.

After D21518:

These parts seem likely resolved once I convince myself the patches so far actually work:

I have a change to add containerPHID locally, but it ends up having relatively high complexity because several other patches (including 20190909.herald.01.rebuild.php) call PhabricatorRebuildIndexesWorker::rebuildObjectsWithQuery(...), which does not work if executed in sequence prior to a worker queue schema change.

This also relates slightly to T13580, but I believe the two issues are addressable independently.

However, I'd like to have a better understanding of how we're reaching this state, and I'm not satisfied that these repositories are going down the "natural" pathway (of changing ref definitions after the import starts) and suspect there is some more complicated interaction at play here.