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

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions