Skip to content

spec(queen): keyed_guard.t27 - claim holder as process boot + pid, supervised admission on a lane board, call cycle at any slot #8632

Closed

Description

@gHashTag

Night loop gHashTag/trios#1729, item 7: harden the keyed actors and the bee dispatcher MVP (#8286, gHashTag/trios#1723). Benchmarks go to #7851.

Problem

The MVP reported three gaps in its own PR (gHashTag/trios#1723, "What this does not do yet"):

  1. The claim's holder. In production the task lease is claimed for the Queen's process name, not for the actor's pid that keyed.t27 claim_is_mine asks for, because the round renews leases by that name. control.t27 claim_lands lands again for its own holder, so under one name every claim "renews" every other. Measured in the two-node simulation: 0 duplicate pickups with pid holders, 273 with the process holder.
  2. The admission actor is unsupervised. One crash ends every later admission, and an admission restarted with its own memory would forget the lanes in use.
  3. The call-cycle check is inert for keyed actors. actors.t27 chain_has / chain_add track slots 0..63 in one u64; the runtime never reuses a slot, so past the 63rd process every call passes.

Plan

A new card, specs/queen/keyed_guard.t27 (actors.t27 and keyed.t27 stay as they are; it imports from both):

  1. A holder is a process boot and a pid in it. claim_lands_for, round_renews, end_releases. The store's statements mirror them; a live test in trios holds them equal at their edges.
  2. The admission is a permanent child of a one_for_one supervisor with a Queen domain's intensity, and its lanes and waiting issues live on a board that outlives it. admit_answer (the admission's decision, moved out of TypeScript), grant_lands, after_admission, lane_outlives_holder, wake_count.
  3. A call's chain is its callers' pids, at most CALL_MAX_DEPTH + 1. on_chain, call_admit_chain.

Tests with real asserts, negative controls for every rule, seal saved. Runtime wiring in gHashTag/trios on actors-next-2.

User Scenarios

  • Given a keyed actor system with the new keyed_guard spec, When a claim is landed for a holder that includes both process boot and pid, Then the round renews leases by that specific holder identity rather than by process name alone, preventing duplicate pickups.
  • Given the admission actor is a permanent child of a one_for_one supervisor with Queen domain intensity, When the admission actor crashes, Then it restarts with its lanes and waiting issues preserved on the board that outlives it.
  • Given a call chain tracking callers' pids up to CALL_MAX_DEPTH + 1, When a call exceeds the maximum depth, Then the call is rejected rather than passing the inert check.

Requirements

FR-001: The spec MUST define claim_lands_for, round_renews, and end_releases with a holder that is a process boot and pid pair.
FR-002: The spec MUST define the admission actor as a permanent child of a one_for_one supervisor with Queen domain intensity.
FR-003: The spec MUST define admit_answer, grant_lands, after_admission, lane_outlives_holder, and wake_count with lanes and waiting issues on a board that outlives the admission actor.
FR-004: The spec MUST define on_chain and call_admit_chain tracking callers' pids with at most CALL_MAX_DEPTH + 1 slots.
FR-005: The spec MUST import from both actors.t27 and keyed.t27 without modifying them.
FR-006: The spec MUST include tests with real asserts and negative controls for every rule, with seal saved.

Success Criteria

  • t27c specs/queen/keyed_guard.t27 compiles successfully and exits 0
  • The compiled spec produces 5 tests covering holder identity, supervised admission, lane board persistence, call chain depth limit, and negative controls
  • All 5 tests pass with exit 0 when executed
  • The spec file specs/queen/keyed_guard.t27 exists and imports from actors.t27 and keyed.t27

Boundary

  • specs/queen/keyed_guard.t27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions