[jgluck96]

Summary

Phase 5.11 of the OSS→private sync. Pure-additive port of _recover_orphan_sending_files from OSS sutando to both stando bridges (telegram + discord), closing a bug class that silently dropped proactive notifications when the bridge crashed mid-send.

The bug class

Both bridges use atomic-claim-by-rename in proactive delivery: results/proactive-*.txt is renamed to proactive-*.sending before the send call, preventing same-tick double-deliveries between concurrent poll iterations. But if the bridge crashes BETWEEN the rename and the actual send (SIGKILL, OOM, unhandled exception), the .sending file is orphaned forever — no poll iteration looks at .sending suffixes.

OSS already had a fix in both bridges. Stando inherited the .sending claim pattern but never inherited the recovery. This PR closes that.

The fix

File	Change	Where it runs
src/telegram-bridge.py	+56 lines (new function + 1-line call)	main() after _single_instance_acquire, before polling loop
src/discord-bridge.py	+59 lines (new function + 1-line call)	on_ready() after Phase 5.10 auto-seed, before create_task(poll_*)

Function bodies are byte-identical to OSS upstream. Pattern: scan RESULTS_DIR for proactive-*.sending files, rename each back to *.txt, log per-file recovery + total count. Fail-open on per-file errors so a single bad file doesn't block bridge startup.

Audit notes — what was NOT ported

OSS addition	Decision	Why
send_reply(task_id: str | None = None) parameter	Skipped	Telemetry plumbing that benefits OSS's outbox_log.append(...) but doesn't fit stando's _emit_channel_metric cloud pipeline. Stando is architecturally ahead here.
from task_archive import find_task_file	Skipped	Dependency of OSS's claim_task rename pattern. Stando doesn't use claim_task. Inert if ported.

These are revisited if the underlying systems converge later.

Minimal-divergence accounting

• Both function bodies are byte-identical to OSS — zero conflict surface against future OSS pulls.
• Pure additive change: 115 line inserts, 0 line edits to pre-existing code. No risk of unrelated regression.
• Net effect: stando's bridges are now byte-closer to OSS on a ~115-line gap that previously had no equivalent code on the stando side.

Test plan

New test

• tests/bridge-orphan-sending-recovery.test.py — 9 cases covering both bridges:
  1. Behavior parity (telegram + discord both recover 2 orphan files end-to-end).
  2. Drift guards — both bridges DEFINE the function AND call it from startup.
  3. Selectivity — only proactive-*.sending is touched; task-*.sending, atomic-write temps, and existing .txt files pass through.
  4. Collision safety — if <name>.sending AND <name>.txt both exist, the .sending is left in place.
  5. Idempotency — second call returns 0; missing RESULTS_DIR also returns 0.

Regression sweep (all green)

• 27 Python tests: discord-bridge-, dm-result-, discord-config, send-allowlist, bridge-marker-no-leak, result-markers, discord-chunker, single-instance, telegram-bridge-* (5), agent-api-result-archive, health-check-phase-57, plus this PR's new test.
• pnpm typecheck clean.

Manual verification (post-merge)

On the next bridge restart, watch the startup output. If the previous process left orphan .sending files behind, you'll see lines like:

  [startup] recovered orphan proactive-1234.sending → proactive-1234.txt
  [startup] recovered 1 orphan .sending file(s)

And the proactive notification will deliver on the very next poll iteration instead of being silently dropped.

Made with Cursor