refactor(server): share attachment message intake#10580

🟠 High orchestration-v2/ThreadMessageIntake.ts:42

Retrying an already accepted launch after a lost response copies the pending attachment to a new random thread-scoped path, then launches.launch returns the existing receipt without referencing that copy. The unreferenced file is never released, so each retry permanently leaks an attachment; perform the idempotency check before claiming or release claimed.claimedPaths when the launch is already committed.

Fixed in c80aae28752480aca3d0ec0d9a773dca4586e821. Shared intake now removes claims not referenced by the returned durable message/events, including accepted launch, command, and send replays. It also removes copies on typed receipt/planning rejections and launch project/receipt failures before message dispatch. The real V2 regression now proves replays leave only accepted files and missing-project/thread requests leave no orphaned copies. The same regression retains the lost-result-after-acceptance case and verifies the original bytes survive. Generic launch/dispatch errors remain ambiguous, so blanket tapError cleanup would reintroduce data loss; those copies are intentionally retained. No new receipt store, journal, lock, or read-after-failure query was added. Focused suites: 38 passed; server typecheck and targeted lint/format passed.

🟠 High orchestration-v2/ThreadMessageIntake.ts:46

launchThread leaks the copied attachment whenever launches.launch fails before accepting the initial message. claimPendingAttachments creates a non-pending final path, so the pending sweep never reclaims it and repeated failed launches accumulate orphaned files; release claimed.claimedPaths on launch failure.

Fixed in c80aae28752480aca3d0ec0d9a773dca4586e821. Shared intake now removes claims not referenced by the returned durable message/events, including accepted launch, command, and send replays. It also removes copies on typed receipt/planning rejections and launch project/receipt failures before message dispatch. The real V2 regression now proves replays leave only accepted files and missing-project/thread requests leave no orphaned copies. The same regression retains the lost-result-after-acceptance case and verifies the original bytes survive. Generic launch/dispatch errors remain ambiguous, so blanket tapError cleanup would reintroduce data loss; those copies are intentionally retained. No new receipt store, journal, lock, or read-after-failure query was added. Focused suites: 38 passed; server typecheck and targeted lint/format passed.

🟠 High orchestration-v2/ThreadMessageIntake.ts:19

Failed dispatchCommand and launchThread calls permanently retain the thread-scoped copies created by claimPendingAttachments, so repeated requests for nonexistent threads or projects leave unreferenced upload payloads on disk and can exhaust server storage. These failures occur before a message or thread is accepted, but no cleanup follows threads.dispatch(...) or launches.launch(...), and the pending-file sweep does not remove the copies. Release the claimed attachments whenever dispatch or launch fails before acceptance.

Fixed in c80aae28752480aca3d0ec0d9a773dca4586e821. Shared intake now removes claims not referenced by the returned durable message/events, including accepted launch, command, and send replays. It also removes copies on typed receipt/planning rejections and launch project/receipt failures before message dispatch. The real V2 regression now proves replays leave only accepted files and missing-project/thread requests leave no orphaned copies. The same regression retains the lost-result-after-acceptance case and verifies the original bytes survive. Generic launch/dispatch errors remain ambiguous, so blanket tapError cleanup would reintroduce data loss; those copies are intentionally retained. No new receipt store, journal, lock, or read-after-failure query was added. Focused suites: 38 passed; server typecheck and targeted lint/format passed.

This catch-all mapError now inspects cause._tag and derives the wrapper's message from cause.message. Per the error conventions, a wrapper's message should come from its own attributes, and statically known tagged failures should be handled with Effect.catchTags where their context is known, instead of tag-sniffing a whole multi-step pipeline's error channel.

^{Posted via Macroscope — Effect Service Conventions}

Fixed in 4cfe3581d4: the RPC launch boundary now handles AttachmentClaimError, ThreadLaunchError, and ServerRuntimeStartupError explicitly with Effect.catchTags. The attachment claim message remains unchanged because it is an existing, safe caller-facing validation message; launch/startup failures retain the existing fixed message. The suggested catchTags-then-mapError sequence would rewrap the translated claim error and erase that message, so the mapping is exhaustive in one catchTags instead. Canonical server typecheck, targeted type-aware lint, formatter and diff checks pass. No behavior or new test machinery was added.