Transactions on Brian Faust

Framework Convenience Has a Boundary

Wed, 01 Jul 2020 00:00:00 +0000

A model was saved inside a database transaction. Its observer dispatched a queue job. The worker started quickly, looked for the record which described its work, and found nothing.

The record existed in the transaction which dispatched the job. It was not yet visible to the worker’s database connection.

Retained history connects that race to successful wallet payments without a corresponding wallet transaction. The job had been published. The state it needed had not.

A Transaction Defines What Must Succeed Together

Wed, 01 Feb 2017 00:00:00 +0000

A booking flow reserved funds, completed the remote booking, and captured the funds. Only then did synchronous response processing fail.

The remote booking existed. The funds were captured. The caller received a failure.

The capture was individually valid, and its own database transaction committed cleanly. It was still too early. We had drawn the success boundary around “remote booking returned” while the operation promised something larger: a complete booking result which the caller could use.

Silencing an Error Does Not Protect the Customer

Wed, 01 Jun 2016 00:00:00 +0000

A shipment-booking request returned without an error. The shipment appeared in the system, so the request looked successful. It had no label and no tracking number.

Persistence had failed after the remote booking completed. A broad catch swallowed the exception, emitted no report or log, and continued. The code met one operational request—do not show customers errors—by returning an object which the customer could not use.

The intent was reasonable. Customers prefer reliable bookings to error messages. But once the system can no longer produce the required result, silence does not create reliability. It converts a known failure into an ambiguous success and hands the investigation to the customer.