Problem
A hold's expiresAt is calculated from the request-entry timestamp after the request may have waited for the supply and per-caller locks. Under prolonged contention, the returned hold can have less than the configured TTL or already be expired.
Capacity remains safe because expired holds stop consuming supply and cannot be confirmed, but the successful response is misleading and creates avoidable retry work for clients.
Small follow-up
- Observe a fresh clock instant after both locks are acquired and immediately before the hold write.
- Recheck grant expiry against the decision instant.
- Calculate
expiresAt from that same instant.
- Add a deterministic PostgreSQL regression that blocks on the supply lock and proves lock wait does not consume the configured TTL.
This is deferred from PR #1092 because it does not permit overselling or unauthorized mutation and is bounded to a contention-path developer experience failure.
Problem
A hold's
expiresAtis calculated from the request-entry timestamp after the request may have waited for the supply and per-caller locks. Under prolonged contention, the returned hold can have less than the configured TTL or already be expired.Capacity remains safe because expired holds stop consuming supply and cannot be confirmed, but the successful response is misleading and creates avoidable retry work for clients.
Small follow-up
expiresAtfrom that same instant.This is deferred from PR #1092 because it does not permit overselling or unauthorized mutation and is bounded to a contention-path developer experience failure.