The Third State

"After you submit a paid request and the line goes quiet, you do not know if it worked. Pretending you do is the bug."

Success and Failure Aren't the Only Answers

Most code models a network call as two outcomes: it worked, or it didn't. That model is a lie the moment money and a network are both involved. You send a paid synthesis request, and then the connection drops before the response comes back. Did the provider charge you? Maybe. Did it produce the audio? Maybe. You genuinely cannot tell from your side. This is the two-generals problem wearing an invoice.

Name the Uncertainty

Bellows refuses to collapse that uncertainty into a convenient lie. A timeout after submission is neither success nor failure — it's a distinct state: ambiguous. Marking it ambiguous is the whole trick. Call it failed and the natural next move is a retry, which risks paying a second time for audio you may already have. Call it success and you might mark a job done that produced nothing. Ambiguous is honest, and honesty is what lets you resolve it correctly later instead of guessing now.

Distinguish Before-Charge From After-Submit

Not every error is ambiguous. If the provider rejects the request before doing any work — bad input, auth error, rate limit — that's a clean failure, safe to retry, because no charge happened. The dangerous zone is specifically after you've submitted and before you've confirmed: a timeout, a dropped connection. Those become ambiguous. The distinction is the difference between "nothing happened" and "something might have."

Code

Three outcomes, because two is a lie·python

async def paid_synthesize(job: Job, binding, settings) -> Outcome:
    try:
        audio = await provider.synthesize(binding, settings, timeout=T)
        return Outcome.success(audio)
    except ProviderRejected as e:
        # Provider said NO before doing work -- no charge. Safe to retry.
        return Outcome.failed(e)
    except (Timeout, ConnectionLost):
        # We submitted. We MAY have been charged. We MAY have audio.
        # This is NOT 'failed' -- a blind retry could pay twice.
        return Outcome.ambiguous(job.request_id)

# 'ambiguous' is a real, persisted state -- resolved later against provider
# history and durable lineage, never guessed away in the moment.

Exercise

Find a call in a system you know that has a side effect you can't take back — a payment, an email send, an inventory decrement. Describe what your code does today if that call times out after the request left your machine. Does it retry, mark success, or mark a third 'unsure' state? If it retries, sketch the double-effect that a timeout-then-retry could cause.

Hint

The test is: 'if this timed out, could the effect have happened anyway?' If yes, retrying is a gamble, and you need a third state plus a way to check what really happened before you act.