Durable actor recovery slice: journal, replay, generation fencing, and leases #52

New issue

Open

opened 2026-09-02 17:26:05 +00:00 by nsaspy · 0 comments

nsaspy commented

2026-09-02 17:26:05 +00:00

Owner

Parent

Epic: #56
Production runtime epic: #47
Prototype retirement: #52

Goal

Extract the generic durable actor-runtime recovery semantics needed by long-lived hosts after the base final execution/Sento/supervision path is green.

This is not application persistence. A host such as Hackmode still owns canonical operation/business state in its own storage. StarLang owns only runtime coordination durability required to recover actor lifecycle/message execution safely.

Dependency order

Do not implement this ahead of the base runtime path:

#42 concrete actor semantics/equivalence;
#57 final supervision semantics;
then this durable recovery slice.

Required semantics

Journal

append-only runtime lifecycle/message records with deterministic identity;
explicit runtime/actor generation in journal identity;
bounded/canonical serialization through final StarLang wire/canonical JSON contracts;
crash-safe record validation and explicit corrupt/truncated classification;
no arbitrary host Lisp objects or application DB handles.

Replay / idempotency

replay only the runtime coordination facts required by final semantics;
deterministic duplicate suppression for replayed lifecycle/message identities;
stale completion from generation N cannot commit against generation N+1;
completed/cancelled/drained work remains terminal;
replay failure is inspectable rather than silently treated as success.

Lease / fencing

time-bound lease/epoch distinct from actor generation;
lease expiry/reacquisition cannot make an old actor ref current;
stale lease holder cannot commit a completion after a newer lease/fence exists;
shutdown/restart releases or expires runtime-owned leases deterministically;
no distributed-consensus claims beyond the actual single/runtime or supported remoting contract.

Host boundary

A host may rebuild application actor state from canonical host storage after restart. StarLang journal/replay must not require serializing Hackmode/Tek9 operation objects as actor state.

The runtime may preserve/recover generic facts such as:

actor logical identity and generation;
lifecycle status;
message/correlation/idempotency identity;
supervisor relationship/restart metadata;
lease/fence epochs;
terminal/cancelled/drained markers.

Mandatory RED-first proof

Using the final runtime:

accept a message/correlation under generation N;
simulate crash after work starts but before a terminal commit;
restart/recover to generation N+1;
inject the old completion and prove stale rejection;
replay journal and prove no duplicate logical terminal effect;
corrupt/truncate the final record and prove explicit quarantine/failure semantics;
expire/reacquire lease and prove old holder cannot commit;
shut down and prove no journal/lease resource leak.

Add a two-operation/service-shaped fixture where one actor recovers while another continues or recovers independently, without importing application-specific state.

Non-goals

no Hackmode/Tek9 persistence;
no generic application event sourcing framework;
no StarIntel storage/broker semantics;
no distributed consensus system;
no hidden retry of arbitrary external effects without host idempotency evidence.

Definition of done

star-journal and star-lease own the final generic durability/fencing semantics needed for service restart, the migration ledger can move the relevant rows out of prototype authority, and a host like hackmoded can recover actor coordination without replaying stale effects or creating a shadow business database.

## Parent - Epic: #56 - Production runtime epic: #47 - Prototype retirement: #52 ## Goal Extract the generic durable actor-runtime recovery semantics needed by long-lived hosts after the base final execution/Sento/supervision path is green. This is not application persistence. A host such as Hackmode still owns canonical operation/business state in its own storage. StarLang owns only runtime coordination durability required to recover actor lifecycle/message execution safely. ## Dependency order Do not implement this ahead of the base runtime path: 1. #42 concrete actor semantics/equivalence; 2. #57 final supervision semantics; 3. then this durable recovery slice. ## Required semantics ### Journal - append-only runtime lifecycle/message records with deterministic identity; - explicit runtime/actor generation in journal identity; - bounded/canonical serialization through final StarLang wire/canonical JSON contracts; - crash-safe record validation and explicit corrupt/truncated classification; - no arbitrary host Lisp objects or application DB handles. ### Replay / idempotency - replay only the runtime coordination facts required by final semantics; - deterministic duplicate suppression for replayed lifecycle/message identities; - stale completion from generation N cannot commit against generation N+1; - completed/cancelled/drained work remains terminal; - replay failure is inspectable rather than silently treated as success. ### Lease / fencing - time-bound lease/epoch distinct from actor generation; - lease expiry/reacquisition cannot make an old actor ref current; - stale lease holder cannot commit a completion after a newer lease/fence exists; - shutdown/restart releases or expires runtime-owned leases deterministically; - no distributed-consensus claims beyond the actual single/runtime or supported remoting contract. ## Host boundary A host may rebuild application actor state from canonical host storage after restart. StarLang journal/replay must not require serializing Hackmode/Tek9 operation objects as actor state. The runtime may preserve/recover generic facts such as: - actor logical identity and generation; - lifecycle status; - message/correlation/idempotency identity; - supervisor relationship/restart metadata; - lease/fence epochs; - terminal/cancelled/drained markers. ## Mandatory RED-first proof Using the final runtime: 1. accept a message/correlation under generation N; 2. simulate crash after work starts but before a terminal commit; 3. restart/recover to generation N+1; 4. inject the old completion and prove stale rejection; 5. replay journal and prove no duplicate logical terminal effect; 6. corrupt/truncate the final record and prove explicit quarantine/failure semantics; 7. expire/reacquire lease and prove old holder cannot commit; 8. shut down and prove no journal/lease resource leak. Add a two-operation/service-shaped fixture where one actor recovers while another continues or recovers independently, without importing application-specific state. ## Non-goals - no Hackmode/Tek9 persistence; - no generic application event sourcing framework; - no StarIntel storage/broker semantics; - no distributed consensus system; - no hidden retry of arbitrary external effects without host idempotency evidence. ## Definition of done `star-journal` and `star-lease` own the final generic durability/fencing semantics needed for service restart, the migration ledger can move the relevant rows out of prototype authority, and a host like `hackmoded` can recover actor coordination without replaying stale effects or creating a shadow business database.

nsaspy referenced this issue

2026-09-02 17:26:05 +00:00

EPIC: Hackmode dogfood — service-grade StarLang actor/runtime #55

nsaspy referenced this issue

2026-09-02 17:26:05 +00:00

Epic: make StarLang safely embeddable in StarIntel services #57