(Or, rather, BlogSite and ShortSite both deal with 404s in a sensible way. They just don't route "/robots.txt", "/favicon.ico", or "/status/".)

This leaves some edge cases doing less-than-ideal things:

A related issue is that if you 404 on the ResourceSite, you hit a cookie exception. This isn't ideal.

We should probably route /robots.txt, but perhaps prevent it from accessing anything?

I don't think those use cases are necessarily bad, there's just a little bit of a slippery slope to, say, "Git sure looks a lot like a database" and then support issues like "it's hard to manage my 3,500 automated review requests".

Adding a data point, "Foist Upon" was a surprise hit among the developers here and additionally we have successfully utilized the conduit API to take advantage of foisting

There are probably also some off-label use cases where, for example, bots create revisions on behalf of users. I'm not thrilled about these, ...

oops 😬

An issue arose when a user loads a page of notifications which include stories they don't have permission to view.

Nothing new has arisen for a while, so presuming this is resolved.

Seems like it works:

I think we can be slightly more general about this, and assume any token beginning with _ is substring search. This covers __FILE__, __construct, etc. Users almost certainly intend these to be substring searches.

Although I didn't look particularly hard, I can't immediately find any more evidence that this is occurring in production.

One remaining artifact here is this configuration option:

This promoted and has been in the Phacility cluster for a few days without issues.

This promoted without exploding.

Can Piledriver be implemented as an Arcanist toolset?

Long ago, we used to write a <package, commit> audit relationship with "AUDIT_NOT_REQUIRED", meaning "This commit affects the package, but package owners don't need to audit it.".

PhabricatorAuditStatusConstants appears to have a set of unused constants:

This is promoting to stable shortly and looks complete to me, thanks!

These contexts are covered:

I dug up another one of these in PHI1439, but there is a lot of text in that issue that I haven't re-read yet.

Evidence increasingly suggests that the root problem here was GET_LOCK() issue in T13627, not an error in an sshd subprocess context.

I deployed this to the hosts affected by PHI2009 yesterday, and it appears to have resolved the problem.