Skip to content

fix: harden rac ingest and outbox handling #1040

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
charmful0x wants to merge 1 commit into
base: feat/rac@1.0
Choose a base branch
from
+279 −77
Open

fix: harden rac ingest and outbox handling #1040

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 7 additions & 3 deletions docs/devices/rac-at-1-0.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -65,7 +65,11 @@ channel's next slot and appending it to the process outbox for delivery.
`-1`, so the first slot is `0`).
2. Stamp the outbound message with `rac-slot = Slot` and `target = recipient`,
plus `rac-channel`/`rac-ratchet` when they differ from their defaults.
3. Append the stamped message to the outbox (`results/outbox`).
Existing top-level RAC control keys, `target`, and `from-*` provenance keys

@samcamwilliams samcamwilliams Jul 24, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't that the responsibility of ~push@1.0, not ~rac@1.0? I can kind of see the logic for it being here, but if I am seeing it correctly it would blow the edges of the abstraction. For example, if push@2.0 wanted to utilize rac@1.0 (or some other device construct), we would end up breaking it in a super counter-intuitive way that would require the dev/us to hack around it in another ugly way, etc.

in `body` are replaced or removed before stamping.
3. Append the stamped message to the outbox (`results/outbox`) at one past the
highest canonical positive numeric key; sparse gaps and noncanonical,
nonpositive, or non-numeric keys are not reused.
4. Set `base/rac-outbound/<recipient>/<channel> = Slot`.

**Response:** `{ok, <base>}` — the base with the outbox entry appended and the
Expand All @@ -86,8 +90,8 @@ first pass and returns the base unchanged on later passes.

**Inputs:** the base is the process state; the inbound message is the request's
`body`, from which `compute` reads `rac-slot`, `rac-channel` (default
`default`), `rac-ratchet` (default `false`), and the sender (`from-process`, or
the message's first committer if absent).
`default`), `rac-ratchet` (default `false`), and the sender (`from-process`).
Tagged RAC messages without process provenance are rejected.

**Behaviour:**

Expand Down
Loading