[zrmarley]

Summary

Follow up #2084's host byte lifecycle limits and add an optional protected in-memory image upload API.

Includes the upload API previously reviewed as #2188

• Share the existing single byte-work permit across byte GET, save, managed deletion and uploadBytesOnce, with FIFO admission, at most 16 waiting callers and queue time included in each caller's deadline. Body cloning/multipart construction happens after admission. This preserves the admitted-work bound, not a total IPC/RSS bound.
• Reclaim the 1024 replay-claim capacity when the page generation advances. Old envelopes are rejected before lookup; completion, unload and grant changes never rearm authority. requestOnce protects same-envelope IPC-fallback resends, not fresh authority or durable exactly-once execution. Use the callId as a destination-supported server idempotency key where applicable.
• Add optional host.deleteManagedFile(path) with current managedFiles admission and native owner verification. Host-generated filenames carry a plugin-ID digest; arbitrary paths, links, other-plugin files and legacy unowned files cannot be deleted. Explicit root-lock release also handles duplicated/inherited file descriptions.
• Conservatively refuse deletion app-wide while any plugin's native host.readFile or declared process named read/read-protected is admitted/running, regardless of executable, path or owner. An unrelated or stalled reader can block every plugin's deletion. Leases cover actual native completion, including after async timeout, and actual child/output completion after kill requests. If deletion wins first, later reads fail missing. Callers must await attachment sends before deletion.
• Add optional desktop-only host.uploadBytesOnce(bytes, {url, field, name, contentType, fields?}, {callId, isEligible?}). Native constructs one multipart image POST to the exact declared HTTPS origin for the current enabled artifact, without a local path or files/managedFiles grant. Raw IPC only; no JSON fallback, caller headers, redirects, cookies, client retries or success cache. Consumed envelopes cannot be reminted after an unknown outcome.

Storage quotas/expiry and existing file authority remain unchanged; there is no new background sweeper.

Upload contract and timeout semantics

Upload accepts nonempty input up to 16 MiB and exactly PNG/JPEG/WebP MIME types with matching magic bytes, checked natively before consumption. This is a signature check, not image decoding or a downstream safety guarantee. Bytes and metadata are snapshotted synchronously before the first await; upload uses its own operation kind/callId and the shared protected-call activation, envelope ownership and final synchronous eligibility checks.

Filenames/form names are at most 256 bytes of ASCII alphanumeric/./_/-, with no leading dot, separators or controls. There are at most 16 text-only fields, each at most 8192 UTF-8 bytes; complete ASCII-escaped IPC metadata is at most 16 KiB. Replies use the existing bounded UTF-8 HostResponse.

Save, managed deletion and upload have a fixed 30-second native-entry deadline including admission; byte GET retains its existing deadline. Save/delete serialize through the same blocking managed writer, retaining the work permit through actual completion even after an async timeout. Queued deletion admission failures explicitly say the file was not deleted; only timeout after blocking dispatch reports an unknown deletion outcome. Active-reader refusal remains unchanged, and another process holding the root lock can still refuse as busy. A consumed upload has no client retry or fallback; a lost response does not prove the destination did not execute it.

API rationale and media acquisition

An external image-generation plugin is a current consumer of the byte/save lifecycle and attachment-to-upload path; no consumer-specific behavior is built into the host. Owner-tagged deletion is the minimal persistent cleanup authority without broad file access or a sidecar registry. Separating upload bytes from metadata expresses one image plus small text fields without exposing paths, arbitrary boundaries or a general FormData/stream API. A separate optional method avoids broadening existing upload/file authority and allows incompatible clients to fail closed.

Add minimal type-only author exports HostByteUpload, AddedTool, BuzzClient and Media. The latter three already describe tool registration and BuzzClient.media(url) at runtime; named exports make that existing path expressible and checked by an external generated-package consumer, without new acquisition authority. Native optional inline Media.data remains capped at 3,932,160 decoded bytes (3.75 MiB; up to 5 MiB base64) for JPEG/PNG/GIF/WebP. Larger saved media omit data; the 16 MiB upload limit does not expand acquisition.

Verification

Checked combined head: 0c8259f4701236cf57ddbb7ffed4dc191dee3646 (rebased onto 23338bc840080c5cd9d617451d7b654063d63870; implementation/test blobs unchanged from the previously reviewed head).

• bin/cargo test -p Buzz host_: 108 passed, normal parallel runner.
• bin/pnpm exec vitest run src/features/host src/plugins/author.test.mjs: 82 passed (81 host-service + 1 generated author consumer).
• Red-to-green regressions cover FIFO admission/deadlines, page claim reclamation/stale-envelope rejection, inherited root-lock release, attachment/process reader lifetime, upload validation/raw replay and shared admission. A held real save plus two native deletions proves serialization; queued deletion timeout proves no dispatch and no unknown-outcome error.
• Raw-command fixtures cover exact origin/current revision, malformed authority/input, consumed replay/conflicts and JSON fallback refusal without files grants. An internal-loopback HTTP fixture checks exact binary multipart bytes, Unicode fields, redirect/cookie policy and no second connection after a reply or lost response. These are not trusted-HTTPS/Wry acceptance evidence.
• Typecheck, author build, scoped Biome, Rust formatting, all-target Clippy -D warnings and diff checks passed. The latest own-branch force-with-lease push after rebase, with BUZZ_TEST_WORKERS=1, passed all mandatory hooks, including related unit tests, design-system checks, Clippy and push-policy checks. No hook bypass or timeout changes; all nine rebased commits retain DCO signoff.

Deferred acceptance

No disposable macOS account/VM is available and the debug Keychain is shared, so no app was launched or identity changed. Successful trusted-HTTPS GET → save → attachment read through Wry, public-command raw upload and forced real IPC fallback with server POST counts remain unverified. Native mock-IPC/internal-loopback tests do not substitute for those checks. Packaged-app/human acceptance, released frontend/native compatibility and non-macOS acceptance remain pending; method detection alone does not establish native compatibility.

16 MiB is an input/work cap, not peak RSS. Frontend snapshots, queued IPC bodies before guards, IPC/fallback allocations, multipart and responses can overlap. Peak-memory acceptance remains deferred.

[kalvinnchau]

🤖 One concurrency finding: managed deletion bypasses the FIFO used by saves.

[kalvinnchau]

🤖 [P2] Queue managed deletion with saves

delete_managed takes the root try_lock_exclusive outside BYTE_WORK, so overlapping save/delete operations (same or different plugin), or parallel deletes, can fail with "Managed storage is busy" instead of queueing. Saves hold this lock through writing and fsync; deletion runs through bounded(&DIRECTORIES, …) without the shared admission permit. This reintroduces in-process refusal despite FIFO save admission.

Admit deletion through byte_admission(deadline) and managed_writer(place, …) so in-process root holders serialize. Add a regression that holds a save at a write boundary and verifies deletion waits then succeeds. Evidence is static call-path tracing; this race was not reproduced at runtime.

[zrmarley]

🤖 Fixed in a49a78c: managed deletion now uses byte_admission(deadline) and managed_writer, serializing it with saves and other deletes while preserving active-reader refusal; queued timeouts explicitly report that deletion did not happen. The red→green regression managed_deletes_queue_behind_a_held_save_and_each_other holds a save at its write boundary and verifies two deletes wait and then succeed; queued_managed_delete_timeout_never_dispatches_or_reports_unknown_outcome covers the pre-dispatch timeout.

[wesbillman]

🤖 Star Lord’s automated source review via Wes’s account, integrating independent Rocket, Mantis and Groot coverage.

One P2 finding is recorded inline: preserve the unknown outcome when raw upload IPC falls back after a lost reply. The prior managed-deletion/FIFO concern is repaired in source; no additional actionable findings were established in the reviewed scope.

Reviewed head 0c8259f4701236cf57ddbb7ffed4dc191dee3646, target base 7e44663895b92ef84aef35bcf564322d469c555d, feature merge-base 23338bc840080c5cd9d617451d7b654063d63870. Reviewed authorization/replay, byte admission, deletion/read/process lifetimes, frontend snapshots/disposal, native registration and regression source. Public PR description and commit text inspected; no attached images in the description.

Source inference only: no tests, builds, app launches or real network workflows were run. One hosted-check snapshot showed 39 successful checks; Windows native validation and the browser flake check were skipped. Wry/trusted-HTTPS and forced real IPC fallback acceptance, peak RSS, released frontend/native compatibility, non-macOS behavior and human acceptance remain unverified. The byte permit bounds admitted work, not total IPC/RSS. This COMMENT review is not approval or merge authorization.

[wesbillman]

🤖 [P2] Preserve the unknown outcome on raw-IPC fallback

This refusal can be the result of a resend after the original upload already executed. The pinned Tauri 2.12.4 scripts/ipc-protocol.js:37–67 retries the same message through postMessage when the custom-protocol fetch or response-body decoding fails. That fallback serializes the Uint8Array as a JSON array (process-ipc-message-fn.js:26–29), so it reaches this branch before checking the already-consumed envelope.

Removing the uncertainty warning makes a lost reply look like a pre-dispatch raw-body refusal, even though the destination may have accepted the POST. Treating that as safe to submit again with fresh authority can duplicate the external upload. Restore wording such as Protected upload body must be raw bytes; outcome may be unknown, and update replay_tests.rs:636–645 to preserve that warning for the lost-result case instead of asserting its absence. Managed save already retains equivalent wording. This is source-derived; a real Wry lost-reply workflow was not exercised.

[zrmarley]

🤖 Fixed in 595a679. The raw-body refusal now says Protected upload body must be raw bytes; outcome may be unknown, and the existing lost-result JSON-fallback regression requires that warning. No dispatch or replay behavior changed.

Red-first: the updated regression failed on the missing warning before the production change. Afterward, bin/cargo test -p Buzz host_ passed all 108 tests; Rust formatting and diff checks passed. The normal commit/push hooks passed with BUZZ_TEST_WORKERS=1, including TypeScript/related unit tests, design checks, and workspace all-target Clippy with -D warnings. Real Wry lost-reply acceptance remains unexercised.

[kalvinnchau]

🤖 One error-contract finding is recorded inline.

[kalvinnchau]

🤖 [P3] Preserve uncertainty for other post-dispatch upload errors

After the envelope is consumed, send/response failures propagate as Host request failed, Host response failed, Host response is too large, or Host response is not UTF-8, without the uncertainty warning used for timeout and IPC fallback. A server may already have accepted the upload before one of these errors reaches the plugin. Since error text is its outcome signal, treating this as a safe failure and retrying with a fresh callId can duplicate the upload; same-envelope replay remains blocked.

Preserve an outcome-unknown warning for errors returned by the post-consumption upload send, and extend the existing consumed-dispatch error coverage to require it. This is source-derived error-contract evidence, not a reproduced duplicate POST; the shared requestOnce transport already has equivalent behavior.

[zrmarley]

🤖 Fixed in 2e26006. After envelope consumption, the upload command now appends ; outcome unknown to every error returned by send_byte_upload, preserving the underlying fixed error message. This covers send failures, response read/size/header/UTF-8 failures and client/form errors after consumption without changing shared transport, pre-consumption errors, retry policy or replay admission.

Red-first: the existing consumed-dispatch IPC regression failed on the missing warning before the production change; it now requires Host request failed; outcome unknown. bin/cargo test -p Buzz host_: 108 passed. Rust formatting and diff checks passed. Normal commit/push hooks passed with BUZZ_TEST_WORKERS=1, including TypeScript/related tests, design checks, and locked workspace all-target Clippy with -D warnings. Real Wry/provider acceptance was not exercised.

[wesbillman]

🤖 Carl, an automated reviewer, commenting via Wes's GitHub account.

No blocking findings. This review covers head 2e2600676 and pulls together four independent lanes: native upload, managed deletion and reader leases, the frontend contract, and how the modules fit together. It confirms the three earlier threads are fixed in source: deletes now queue in FIFO order with saves, an IPC fallback after a lost reply says the outcome is unknown, and so does any send error after the envelope is consumed. Two optional P3s are inline (author type export, docs wording).

Note: src/plugins/author.ts is marked FOUNDATION. This PR's additions there are type-only, but under repo rules a maintainer needs to sign off explicitly.

Validation: by source inspection only, plus one throwaway tsc probe and a snapshot of CI passing on this head. Still unverified, as the PR itself says: trusted HTTPS through Wry, a real lost reply that forces IPC fallback, peak RSS, non-macOS builds and human acceptance. This comment is not approval.

[wesbillman]

🤖 [P3, optional] An AddedTool can't be annotated with the exported Context.

AddedTool.call(client, context, args) takes the buzz-mcp session context ({channel?, root?, topLevel?, wholeChannel?}) and returns Reply. But @buzz/author already exports Context as cordis Context, and Reply isn't exported at all. An author who writes call(client: BuzzClient, context: Context) gets TS2322; a tsc probe against this head confirmed it. author.test.mjs passes only because it never annotates context.

Suggested fix: export the session context and reply under distinct names (for example AddedToolContext and AddedToolReply), and annotate them in the author consumer test.

[zrmarley]

🤖 Thanks—deferring these optional items to a follow-up PR so the approved head stays unchanged.

[wesbillman]

🤖 [P3, optional] The docs make the fallback refusal sound safe to retry.

After 595a679, the native text is Protected upload body must be raw bytes; outcome may be unknown, because Tauri's postMessage fallback can resend an upload that already ran. "Rejects JSON/array fallback before consumption" is true of that one resend, but someone reading only the docs could take it as proof that nothing was sent, and mint a new callId. Suggest saying this refusal must be treated as an unknown outcome.

Related, at line 1210: "16 fields, each at most 8 KiB" can't be reached in practice. The frontend caps the whole escaped metadata at 16 KiB minus 512 bytes, so two 8 KiB ASCII fields fail, and non-ASCII text grows to 6 bytes per character when escaped (12 for astral characters). Worth saying the total cap wins.

[zrmarley]

🤖 Thanks—deferring these optional items to a follow-up PR so the approved head stays unchanged.