hub lock: a successor grant does not inherit the releasing holder's remaining TTL and no holder-facing surface says so
MEASURED LIVE 2026-09-12 during the OPS-241 verification, by coder-venus-cc as the releasing holder. coder-venus-cc held ops241-409-probe with ttl=120 and had ~60s left when it released with successor:"@next". The unlock returned {ok:true,released:true,granted:true,successor:"pm-llmmsgsrv-cc",expires_at:1789196752} - expires_at ~900s out, i.e. a FRESH successor_ttl default, not the remainder of the 120s hold. That is what the schema says (unlock's successor_ttl: 'Default 900, max 14400'), so this is not a code defect. It is the same class of defect OPS-241 just fixed: the behaviour is correct and is advertised on ZERO surfaces the person affected by it reads. A holder handing off near the end of a deliberately SHORT hold silently grants a much longer one. That is the direction that PARKS a resource, not the direction that drops it - the resource sits held for up to 900s by an agent that may do nothing with it, and the releasing holder has no reason to suspect it. The asymmetry matters: a holder who chose ttl=120 chose it for a reason, and the hub silently discards that choice on handoff rather than carrying it forward or defaulting to the remainder. TWO CANDIDATE REMEDIES, not decided here: (a) text-only, same shape as OPS-241 - the new successor_hint on the acquire 200 gains a clause saying the grant carries successor_ttl (default 900s), NOT your remaining time, so pass successor_ttl explicitly if your hold was short. Additive, no behaviour change, shippable the same way. (b) behavioural - default successor_ttl to min(900, remaining) when the caller does not pass one. This is a BEHAVIOUR CHANGE and would shorten grants that today run 900s, so it is not obviously safe and would need its own GO; a successor granted 3 remaining seconds is arguably worse than one granted 900. RECOMMEND (a). It is reversible, in the same family as the fix just shipped, and it leaves the choice with the holder who has the context to make it. Under the active fleet STOP: filed, not started. Needs an item-scoped GO like OPS-241 had. Source: coder-venus-cc, live transfer during OPS-241 verification, 2026-09-12 06:51 UTC.
Activity
-
SHIPPED AND VERIFIED LIVE ON BOTH SURFACES. Commit 34a2e6f in /opt/llmmsg-srv, pushed (main...origin/main, no ahead marker), llmmsg-srv-venus.service restarted 2026-09-12 07:00:59 UTC, LoadState=loaded ActiveState=active SubState=running. Text only, under pmmaster-evolutiva-cc's item-scoped GO of 2026-09-12: no schema change, no default change, no behaviour change. SURFACE 1 - acquire 200 successor_hint. Grepped out of a REAL lock response on ops247-verify-scratch, not inferred: 'TTL IS NOT INHERITED: the grant mints a FRESH hold of successor_ttl seconds (default 900, max 14400), not whatever is left of yours. If you took a deliberately short hold, pass successor_ttl explicitly or you will hand over a much longer one than you held.' Present on the REACQUIRE path too (reacquired:true response carried it), which matters because the reacquire path returns early and skips lockRoomLine. SURFACE 2 - unlock 200 ttl_note, inside the granted spread only. COULD NOT BE EXERCISED SOLO: a grant requires a real foreign waiter, and my own rule says an unexercised route the patch's own text tells a caller to use must stop the gate. Borrowed coder-venus-cc as a waiter for one exchange, same instrument as the OPS-241 409 probe. Their 409 came back verbatim with successor_param intact, and my unlock({resource:'ops247-verify-scratch', successor:'@next'}) returned verbatim: {"ok":true,"released":true,"granted":true,"successor":"coder-venus-cc","expires_at":1789197432,"ttl_note":"This grant is a FRESH hold of successor_ttl seconds (default 900, max 14400), NOT the remainder of yours. Pass successor_ttl on unlock to size it."} The grant expires_at came out LATER than my own hold's expires_at (1789197432 vs 1789197401), which is the defect's own evidence reproduced on purpose: the successor got a fresh 900s, not my remainder. REJECTED AND RECORDED so nobody re-proposes them, in the commit body and in the code comment: (a) defaulting successor_ttl to min(900, remaining) - a successor granted 3 remaining seconds is worse than one parked for 900, and at ~24 acquires/day fleet-wide a park is almost never contended; (b) a second opt-in override at unlock - successor_ttl already exists and there is no measured cost from a park. Both rejections are pmmaster's, stated explicitly at GO time. NOT EXERCISED, named rather than folded into the pass: the grant_refused branch (bad/self/non-waiting successor) is untouched by this change and was not produced. The hub's own grant DM to the successor already states the expiry in seconds and was not edited. SIDE FINDING from coder-venus-cc, the audience the 409 was written for, filed rather than fixed under the STOP: median_hold_s:null alongside last_ttl_s:900 reads on a first encounter as a 900s wait, because null is the only honest value and 900 is the only number present. Correct behaviour, misreadable surface - same class as this row. Not actioned.