Skip to main content

Module suspend

ff_backend_postgres

Module suspend 

Source
Expand description

Suspend + resume plumbing for the Postgres backend.

Wave 4 Agent D (RFC-v0.7 v0.7 migration-master).

This module is the landing pad for the 4 suspend-family trait methods (suspend, observe_signals, list_suspended, claim_resumed_execution). The current tranche ships the composite-condition evaluator as a pure-Rust helper (evaluate) and the parititon-slot helper (slot_of); the SQL bodies for the trait methods land together with the Wave-4 claim/lease plumbing being built in parallel (Wave 4 Agents A/B/C).

§Composite evaluator placement

Q11 pinned composite-condition evaluation at one of the three SERIALIZABLE sites; we run the evaluator Rust-side inside the SERIALIZABLE transaction (not as a plpgsql stored proc) because:

  1. The declarative ResumeCondition + CompositeBody types already live in ff-core::contracts; replicating the logic in plpgsql would double-maintain a non-trivial tree walker.
  2. SERIALIZABLE already serializes reads + writes on the satisfied_set / member_map JSONB columns the evaluator touches, so moving the eval into pg buys no isolation.
  3. Rust-side eval keeps the evaluator unit-testable without a live Postgres (see evaluate tests below).

The Valkey backend runs the equivalent logic in Lua; this is the only evaluator divergence and is deliberate per the rationale above.

Functions§

evaluate
Evaluate a ResumeCondition against the set of signals delivered so far. Returns true iff the condition is satisfied.
slot_of
Map an ExecutionId to its partition slot under the deployment’s PartitionConfig. The i16 return matches the column type on every partitioned table in migrations/0001_initial.sql.
slot_of_partition_key
Convert a PartitionKey to its slot index for schema-partition keying. Returns None if the key is malformed.

Type Aliases§

SignalsByWaitpoint
Map from waitpoint_key → list of signals delivered to it. This is the shape [ff_suspension_current.member_map] deserialises into on the Postgres side — signals are keyed by their target waitpoint, so the evaluator can answer “did this waitpoint fire?” without a per-signal wp lookup.