Skip to content

Verifiable run_id → email linkage (+ decide: connect or delete legacy workflow_runs) #1832

Description

@sweetmantech

Follow-up to chat#1829 (task-email pipeline, resolved 2026-07-01). Auditing task emails (skills#69) surfaced that we cannot deterministically tie a Trigger.dev run to the email it sent — the audit joins them by account + timing. This issue tracks making that link verifiable, and removing the orphaned open-agents workflow_runs table.

Decision (2026-07-01, @sweetmantech): delete the legacy open-agents artifacts — the workflow_runs/workflow_run_steps tables and the open-agents mono submodule. They've been orphaned since 2026-05-27; the verifiable-linkage goal is solved by threading a real chat_id into /api/emails (which also fixes the footer-404 link), not by reviving the table.

Goal

Given a Trigger.dev customer-prompt-task run_id, deterministically retrieve the email it produced from email_send_log (subject, body, status) — and the reverse — without account+timing heuristics. And: 100% of task emails must carry a working footer "continue on Recoup" chat link (today 0% do). The same missing chat_id blocks both. Tables involved: email_send_log (chat_id currently null), chats, and the stale workflow_runs/workflow_run_steps. Secondary: delete the stale open-agents tables and the open-agents mono submodule so the schema and repo reflect reality.

PRs (updated 2026-07-01)

PR Item Base State
skills#69 recoup-internal-task-email-audit — standing task-email health audit (surfaced this gap; documents the workaround + stale-table warnings) main ✅ merged 2026-07-01 — see Done
(no PR yet) Thread chat_id into POST /api/emails → deterministic run_id ↔ email + footer chat link on 100% of task emails (today 0%) main 🔜 not started — primary fix
(no PR yet) Delete workflow_runs + workflow_run_steps (open-agents legacy) — drop-table migration + regen types main 🔜 not started — decided 2026-07-01
(no PR yet) Remove the open-agents codebase from the mono submodules main 🔜 not started — decided 2026-07-01

skills#69 is independent and can merge now. The chat_id fix is the primary deliverable (it's what gets task emails to 100% footer-link coverage and verifiable run_id → email). The two deletes are cleanup, unblocked and independent.

Done

  • skills#69recoup-internal-task-email-audit (surfaced this gap).
    ✅ Merged 2026-07-01 (squash to main, commit c501770). The standing task-email audit; it revealed that run → email can only be matched by account + nearest timestamp (ambiguous for multi-run accounts — Apache had 2 runs), which is what this issue makes verifiable. It also documents the stale-table warnings (workflow_runs/scheduled_actions) noted below.
    Verified: CI green (check_resolvable, run_resolver_eval, validate_manifests); validated on the 2026-07-01 prod run.

Open — verifiable linkage

  • Thread the real chat_id into POST /api/emails → deterministic run_id ↔ email AND a footer chat link on 100% of task emails. (no PR yet)
    • Why: email_send_log.chat_id is null on every send — agents call /api/emails without it. One gap, two failures:
      1. No chat link. The footer's "Or continue the conversation on Recoup: …/chat/{roomId}" line only renders when a chat_id is present (getEmailFooter.ts:11,24). Evidence (2026-07-01): 0 of 9 delivered task emails carried a chat_id/room_id, so none had the chat link (incl. the Apache→onerpm one that surfaced this). Every email still gets the "reply to this email" footer note — just never the link.
      2. No exact linkage. The audit must match run → email by account + nearest timestamp — ambiguous when an account fires >1 run/window (2026-07-01: Apache had 2 runs, LV8R 3). [skills#69 § 2 "join caveat"]
    • Fix: the sandbox agent passes the run's real chat_id on every /api/emails send (via the recoup-platform-api-access skill + recoup-platform-email-helper), so email_send_log.chat_id is populated → email → chat → run is exact and getEmailFooter renders the link. (Alternative for linkage only — tagging the send with the Trigger run_id — does not fix the footer, so it's insufficient on its own.) Prod host is already correct (getFrontendBaseUrlchat.recoupable.dev); the preview host bug is the separate footer-404 fix from chat#1829, needed for preview correctness only.
    • Done when:
      • 100% of task emails include a footer "continue on Recoup" link that resolves to the real chat (spot-check ≥5 of a day's sends via the audit — body_html_has_chat_link / chat_id present).
      • For a given run_id, one query returns the exact email_send_log row(s) it produced — no timing heuristic — verified on ≥2 multi-run accounts.

Open — delete legacy open-agents artifacts (decided 2026-07-01)

  • Delete workflow_runs + workflow_run_steps (open-agents legacy).

    • Why: created by database migration 20260501000001_open_agents_workflow_runs.sql for the deprecated open-agents app; the current recoupable/api never reads or writes them — the only reference is generated types/database.types.ts. Last write 2026-05-27; ~90 stale rows.
    • Fix: drop-table migration in recoupable/database; regenerate database.types.ts; confirm no remaining refs (grep workflow_runs clean outside generated types).
    • Done when: both tables dropped on prod; types regenerated; grep clean.
    • (B) Repurpose as the run↔chat bridge. Superseded 2026-07-01 — the verifiable linkage is solved by threading a real chat_id (above), not by resurrecting an open-agents table + adding a new write path in runAgentWorkflow.
  • Remove the open-agents codebase from the mono submodules.

    • Why: open-agents is deprecated — its only live footprint was the stale workflow_runs table (deleted above). It lingers as submodule(s) in the monorepo (open-agents/, plus stray open-agents-worktree/ / open-agents-flat-layout/ copies), adding dead weight and polluting greps.
    • Fix: deregister the submodule — git submodule deinit -f open-agentsgit rm open-agents → drop the .gitmodules entry + .git/modules/open-agents; remove any stray worktree/flat-layout copies. (mono repo change.)
    • Done when: open-agents* no longer appears in .gitmodules / git submodule status; the monorepo greps/builds clean without it.

Architecture notes

  • ⚠️ Do NOT use workflow_runs or scheduled_actions.last_run/next_run for run history — they are stale. workflow_runs stopped updating 2026-05-27; scheduled_actions.last_run last set 2025-10-20, next_run 2025-11-01 (not maintained by the current Trigger.dev scheduler). Run history = the Trigger.dev Management API (GET /api/v1/runs, task customer-prompt-task, tag account:<id>); activity = chats/chat_messages. (Already baked into skills#69.)

Source references

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions