Skip to main content

Module caps

ff_core

Module caps 

Source
Expand description

Backend-shared capability matching predicate (RFC-v0.7 Q7).

Why this module exists. ff-backend-valkey and ff-backend-postgres both need to answer: “does worker W satisfy execution E’s required_capabilities?” In Valkey that’s a Rust short-circuit in the scheduler + authoritative Lua subset-check in ff_issue_claim_grant. In Postgres it’s a WHERE required_caps <@ worker_caps GIN query. The predicate is identical across backends; only the storage (CSV field vs text[]) differs.

This module owns the pure-Rust predicate so both backends share one definition + one test suite. The Valkey-side Lua (lua/scheduling.lua parse_capability_csv + missing_capabilities) remains the atomic authority inside the FCALL — this is a fast-path short-circuit.

Callers today:

  • ff-scheduler::claim — Rust short-circuit before quota admission.
  • ff-backend-postgres (future) — direct predicate in the admission SQL / in-process query layer.

Wire shape. required_capabilities is stored as a comma-separated CSV on the Valkey contract layer (RoutingRequirements::required_capabilities is serialized to CSV when written to the execution hash). Postgres will store as text[]. This module accepts both:

The predicate semantics are case-sensitive subset: every non-empty token in the required set must appear verbatim in the worker’s CapabilitySet. An empty required set trivially matches any worker (backwards-compat default; see RoutingRequirements rustdoc).

Bound constants (crate::policy::CAPS_MAX_BYTES, crate::policy::CAPS_MAX_TOKENS) live in ff-core::policy and are enforced at ingress — not here. This module is a pure predicate.

Structs§

CapabilityRequirement
A pre-parsed capability requirement (the “execution requires X” shape).

Functions§

matches
Subset predicate: every required token appears in the worker’s set.
matches_csv
CSV-form subset predicate. Used by ff-scheduler::claim so the HGET result can be fed in directly without parsing allocation.