(Of course, it'll probably just work the first time now...)

The export process is already robust at a coarse level: the dump is retained on disk and the process can be retried at the "upload the whole file again" level, then picked up with bin/host export using the --database or --database-file flags (probably with --keep-file).

The (anonymized) error the process encountered occurred while transferring the dump to central storage was:

Per above, this was partially mooted by the house framing rotting and partially resolved by me being generally pretty satisfied with the "Stop or Prop".

These are still stuck in a manufacturing backlog.

About a year later, I still like PCB manufacturing in theory, but haven't actually manufactured any more PCBs.

A year or so later:

I redid the clogged sink according to the schema above and haven't had any issues with it so far. I think this is probably an approximately reasonable map for tackling plumbing problems that might arise in the future.

For the moment, the customer has pivoted to knitting.

The customer requirement for "NO MUSIC!!!" abated before I got around to pulling the vehicle apart, so I'm giving up on this one.

Well now, that is certainly a nice rock.

In D21862#279385, @epriestley wrote:

I'll see about getting it upstream.

See D21862.

Next issue: can't pull from secure.

Issue 3:

With bin/provision events working again:

Your suggested patch looks correct to me, insofar as I recall what a computer looks like. I'll see about getting it upstream.

I use a rock.

Things I've figured out:

I haven't used heat-set inserts yet and I'm not sure if they're trustworthy or not.

Bobbin Case

Found two more quick issues

• Adding search results to dashboard hit an error
• Viewing the prototype calendar event failed after creating an event

Looking at the rest of the UT failures I think those are due to updated/newer versions of linters emitting slightly different results.

Fix new exception message to be phtranslated

Correct the check for an empty username

Revert addition of custom error-types

One actual logical issue inline.

Fine as-is, but see inlines about Conduit error behavior.

One more simplification

Some simplifications

This version looks correct to me in all non-pathological cases, thanks!

I tried creating, updating, and landing a diff revision with the change to throw an exception and none of the workflows were interrupted/error'd.

Switch to using coalesce(), revert json parsing behavior change and throw exception instead, update .editorconfig