Fief.Key.Server (Fief v0.1.0)

Copy Markdown View Source

The per-key process (implementation.md §7): a GenServer wrapping the user's Fief.Key module. Started by Fief.Key.VnodeImpl from the agent — restart: :temporary (a crashed key process is not restarted; the next message cold-starts, or escheats per the migration machine's authorization) — under either the impl's agent-linked DynamicSupervisor (on_fence: :terminate) or the instance's Fief.Key.Limbo (:continue/:callback — outside the agent's link tree, so the fence kill does not reach them; design §8).

Replies go to from directly via Fief.Vnode.reply/2 — the agent never blocks on user code. The wire between impl and server (all plain sends; the impl holds the monitor):

  • {:fief_key_msg, msg, from} → user handle_message/3
  • {:fief_key_freeze, deadline_ms} → the transfer freeze advisory, delivered as an EEP 76 priority message (it skips the mailbox backlog). Optional handle_freeze/2 decides: {:noreply, _} keeps draining (the queued extract arrives in order), {:extract, _} ships immediately, {:stop, reason, _} dies with no residual. Dropped silently if the callback isn't exported. After it, this incarnation always stops.
  • :fief_key_extract → user extract_state/1, report {:fief_key_extracted, key_id, blob} to the agent, stop :normal — the old process stops inside the handover, before any grant ships (exactly-one-live-process-per-key, design §6.3 step 3). Quiescing is mailbox order: the extract request queues behind in-flight messages.
  • {:fief_key_fence, deadline_ms} (on_fence: :callback only) → user handle_fence/2; {:stop, reason} stops, {:continue, state} keeps serving (and survives the kill — this server is limbo-supervised). An absent callback stops :fenced (the conservative reading).

The open mailbox (routing rule — docs/key-redesign.md §3.2)

Mirrors the Fief.Vnode M6 handle_info routing rule. The framework claims its reserved messages (the ones above, plus any future framework message — the fief_key_-prefixed tag is reserved, an atom or leading tuple element, and unrecognized ones are dropped, never handed to user code). {:timeout, ref, msg} is claimed by ref, never by shape; the server arms no timers today, so every one is delivered whole to the user. Everything else goes to the optional handle_info/2 if exported, else is dropped silently (today's stray behavior). Every path — user handle_info included — ends with the :handled checkpoint, so a seam-adapted key stays explorable.

A fief lib process: binds the sim context it inherits from the impl (Fief.Sim.capture/0 in the agent, passed in opts — build-order M6 decision) at init and ends every handling with the :handled checkpoint.

Summary

Types

The start mode carries both the Fief.Key source and the ctx.origin that explains it (§4.1 of docs/key-redesign.md); init/1 forwards both to the single init/3 callback.

Functions

Returns a specification to start this module under a supervisor.

Types

start_mode()

@type start_mode() :: {Fief.Key.source(), Fief.Key.origin()}

The start mode carries both the Fief.Key source and the ctx.origin that explains it (§4.1 of docs/key-redesign.md); init/1 forwards both to the single init/3 callback.

Functions

child_spec(init_arg)

Returns a specification to start this module under a supervisor.

See Supervisor.

start_link(opts)