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, but 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. The framework did exactly what the code asked. The shortcut failed because its lifecycle was smaller than the business operation.

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, and 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

One of our shipment-booking paths returned success after it had already failed. The remote booking existed and so did a local shipment, but the shipment had no label and no tracking number. From the customer’s point of view, the one thing we had promised to do was not done.

The failure happened while persisting the carrier response. A broad catch swallowed the exception, reported nothing, and let the request continue. This was meant to serve a reasonable operational goal: do not bother customers with errors if we can avoid it. Instead, we gave them a broken shipment and called it a success.