Adjusting log_warnings = 2 in production (to get connection aborts into the error log) is also possibly desirable, although the background level of connection abortions (general network flakiness, server restarts during deploy, wait_timeout on very long-running demons?) may be high enough that this is more noise than signal.

To reproduce this easily:

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.

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

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

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

Yeah, this is still in a transitional state, it's just been stalled for a bit (not blocked by anything, just other stuff has been getting attention). The two major issues I'm aware of right now are:

Another general note is that we also require users go through this flow if they're setting a password for the first time on an account which does not already have a password. For example, this workflow will set up the "set your own password" flow:

Rough intentions here:

Potentially don't allow the "Send a login link to your email address" action at all if the corresponding Phab account is already only linked to external accounts for authentication and the installation does not use passwords? But I might lack technical understanding here.

We also need --enable-zip to get the zip extension, to get the ZipArchive class, so "Export to Excel" works. See upcoming change on T13342.

This is super old and doesn't have any apparent reproduction instructions.

a logical clock to complement the wall-time clocks

From D20653:

Oh, sorry, I misread which half you were asking about.

Yeah, diffusion.rawdiffquery and diffusion.filecontentquery both do this.

An adjacent issue is that PhabricatorMarkupCache is not currently marked as having cache persistence (PhabricatorConfigTableSchema::PERSISTENCE_CACHE), so the data dumps even when we do not intend to dump data for readthrough caches.

I assume this is being done already in the Phacility cluster on some level when repositories get really large, but I'm not particularly sure how to perform this migration.

Deprecate conduit sessions and conduit.connect.
Support direct token-based auth (?token=abdef123) and make this the standard.

D20647 should fix this. It isn't very satisfying as a general resolution.

The renderHTMLFooter() method does a bunch of Javascript stuff and isn't actually related to the page footer, but PHUIRemarkupView and renderObjectRefForAnyMedia() were enough of a hint that think I have a reproduction case locally now -- let me figure out what I actually did and this will likely be fairly easy to fix.

@20after4, any chance there's a stack trace for this in the webserver error logs? I can't immediately figure out how to reproduce this locally.

Just thinking out loud: