A write can commit and the caller still gets nothing back. From where the caller sits that looks like a failure. At the destination the work is done, so a second attempt that treats the first as failed ends up being a second mutation.

While qualifying ImportFlow’s gateway design we wanted to know what a caller is left with in that state, so we forced it on purpose and looked at what the database and the gateway were holding afterwards.

A 504 after the commit

In an earlier hosted gateway qualification, a test-only fault returned HTTP 504 after the destination operation had already committed. The fault was injected on purpose, and a separate audit agent reproduced it on a disposable hosted Supabase project.

The caller got HTTP 504. The test reported synthetic_response_lost_after_commit. The durable status showed one inserted row, and an independent SQL count found exactly one row in the table.

So the caller was holding a 504 while the table held the data.…