To reproduce this easily:

I'm likely going to propose some variation of this change, but focus it on max_allowed_packet and on emphasizing that there are two different copies of this setting with different error/failure behavior.

We could also consider these things:

So actual actionable stuff here is:

Bumping max_allowed_packet to 1G in the server config resolved things. The export process then spent a long time doing a bin/files migration (which could use a progress bar, maybe) and is now doing a dump (which could too, although I'm less sure of how we'd build one).

I adjusted innodb_log_file_size to 1GB and attempted the import again, but ran into the same issue.

Let me hold this until I'm more confident I'm on the right track.

The "age of the last checkpoint" error appears to primarily implicate innodb_log_file_size, which is currently set to the default value (5MB):

I'll also double check wait_timeout and interactive_timeout...

Aha! The MySQL error log actually appears to have something useful:

Run it with source ...;

Unzip the dump before running it.

Look at the unzipped dump and see if line 13935 is bad in some obvious way.

(Whatever the resolution is here might also motivate tailoring our restore/import instructions, since this error is pretty opaque and the next steps aren't obvious.)

(Internally, see also PHI1329.)

See also https://trac.wildfiregames.com/wiki/Phabricator#Downloadapatch where a tedious workaround is needed in order to apply patches to a mirror of an SVN repo that is updated once a day:

Not all of this has landed yet, but once it does:

(Noted in T13346 before I land this and we forget about it.)

I can do that since I was just fiddling around in there.

Yeah -- I lean toward thinking that we probably should make bin/auth lock also lock the guidance messages too.

Yeah -- I lean toward thinking that we probably should make bin/auth lock also lock the guidance messages too. This class of attack feels like a bit of a stretch since no one reads instructions anyway, but letting an attacker replace the login screen with This page has moved temporarily, click [[ here ]] to go to the new login page. and then 9,000 newlines to push all the actual login controls off the page is at least sort of plausible-attack-flavored.

Are we worried about attackers changing the guidance to something like "To prove that your Phabricator account is in use, please email the following link to bob.hackerman@gmail.com and don't read the rest of this email"?

It may be useful to provide helper methods to support normalizing these actor types (e.g., email addresses should be case-insensitive).

• Correct "messags".