Deadlines & timeouts

In one line: every operation carries an absolute deadline; when it passes, a would-be hang becomes a typed exception — Typhon never blocks forever.

A deadline is a monotonic point in time, not a duration — set once, it propagates through the whole transaction / unit-of-work context and every blocking primitive it touches (lock acquisition, WAL backpressure, page-cache backpressure). Cooperative cancellation checks it at each wait point, so a contended lock or a saturated WAL surfaces as LockTimeoutException / WalBackPressureTimeoutException / PageCacheBackpressureTimeoutException — all under the TyphonTimeoutException family — rather than an indefinite stall. Timeouts are the canonical transient failure: IsTransient is true, so a retry loop can back off and try again.

You set the budget through options (TimeoutOptions, per-transaction deadlines); the engine does the propagation. The point is predictability: in a real-time server, a bounded failure you can catch and retry beats an unbounded wait that blows your tick budget.

How it relates

• Errors & failures — timeout exceptions are a family under TyphonException, all IsTransient.
• Transaction / Unit of Work — carry the deadline; every wait they make respects it.
• Tick — why deadlines matter: a stall would overrun the tick budget.

In the API

• TimeoutOptions — configures the default deadlines / budgets.
• TransactionTimeoutException / LockTimeoutException / WalBackPressureTimeoutException / PageCacheBackpressureTimeoutException — the typed timeouts, all under TyphonTimeoutException.

Learn & use

• Feature detail: Deadline & timeout propagation · deadline & cooperative cancellation · timeout exceptions
• Narrative: Guide ch.6 — operating