Add BBP worker recovery idempotency #32

Merged

lost-rob0t merged 12 commits from agent/star-lang-bbp-run-idempotency-v1 into main

2026-07-23 18:01:32 +00:00

lost-rob0t commented

2026-07-23 15:34:55 +00:00

(Migrated from github.com)

What

add worker-level replay protection keyed by BBP run-id
return the stored tool result when the same run is delivered again
reject reuse of a run-id for a changed tool or target
make identical register-program replay preserve completed runs
reject changed registration metadata instead of resetting aggregate state
expose stored run lookup through a defensive-copy API
return stable terminal conflict codes
load recovery protection in the remote BBP runtime
add focused SBCL conformance and live two-process Sento coverage
document the recovery contract in STAR-LANG-RESEARCH-016

Semantics

same program-id + run-id + tool + target
  -> replay stored result
  -> do not invoke external tool again

same program-id + run-id + changed tool or target
  -> terminal star.bbp.run-id-conflict
  -> do not invoke external tool

same program-id + name + normalized scope
  -> replay existing registration
  -> preserve completed runs

same program-id + changed name or normalized scope
  -> terminal star.bbp.program-registration-conflict
  -> preserve existing state

Why

Durable main-gserver recovery will resend pending commands after a restart. It may also replay program registration before command redelivery. The worker must preserve aggregate history across both operations; otherwise recovery could launch the same scanner twice.

Verification

exact run replay returns the original result
external runner call count remains one
program run count remains one
stored result lookup returns a defensive copy
conflicting run request receives a stable non-retryable error
identical registration replay preserves completed runs
conflicting registration receives a stable non-retryable error
live Sento test forces distinct main-dispatch idempotency keys through the same worker identities
worker call-count assertion proves replay protection occurs at the worker

Stack

This draft is based on agent/star-lang-bbp-runtime-config-v1 / PR #31.

append-only main-gserver runtime journal
pending-command restoration and redelivery after worker registration
terminal dispatcher replay restoration

## What - add worker-level replay protection keyed by BBP `run-id` - return the stored tool result when the same run is delivered again - reject reuse of a `run-id` for a changed tool or target - make identical `register-program` replay preserve completed runs - reject changed registration metadata instead of resetting aggregate state - expose stored run lookup through a defensive-copy API - return stable terminal conflict codes - load recovery protection in the remote BBP runtime - add focused SBCL conformance and live two-process Sento coverage - document the recovery contract in STAR-LANG-RESEARCH-016 ## Semantics ```text same program-id + run-id + tool + target -> replay stored result -> do not invoke external tool again same program-id + run-id + changed tool or target -> terminal star.bbp.run-id-conflict -> do not invoke external tool same program-id + name + normalized scope -> replay existing registration -> preserve completed runs same program-id + changed name or normalized scope -> terminal star.bbp.program-registration-conflict -> preserve existing state ``` ## Why Durable main-gserver recovery will resend pending commands after a restart. It may also replay program registration before command redelivery. The worker must preserve aggregate history across both operations; otherwise recovery could launch the same scanner twice. ## Verification - exact run replay returns the original result - external runner call count remains one - program run count remains one - stored result lookup returns a defensive copy - conflicting run request receives a stable non-retryable error - identical registration replay preserves completed runs - conflicting registration receives a stable non-retryable error - live Sento test forces distinct main-dispatch idempotency keys through the same worker identities - worker call-count assertion proves replay protection occurs at the worker ## Stack This draft is based on `agent/star-lang-bbp-runtime-config-v1` / PR #31. ## Next - append-only main-gserver runtime journal - pending-command restoration and redelivery after worker registration - terminal dispatcher replay restoration