fix(workflows): restore interactive-loop cross-gate session continuity (reverts #1923)

[Wirasm]

Summary

• Problem: fix(workflows): interactive loop resume uses fresh session on first iteration #1923 forced a fresh Claude session on the first iteration after every interactive-loop approval gate, so the agent lost all memory of its prior turns across the gate (Loops with 'interactive:true' always start a fresh AI session, losing previous-loop conversation continuity (regression introduced by #1923) #2004). It broke the core use of interactive loops — a multi-turn conversation/interview/iterative-refinement steered by a human across gates.
• What changed: Reverts fix(workflows): interactive loop resume uses fresh session on first iteration #1923 — removes the (isLoopResume && i === startIteration) term from needsFreshSession in dag-executor.ts, restoring loop.fresh_context || i === 1, so a resumed iteration re-threads the stored gate session id instead of forcing undefined. Restores the resume test assertion (sessionArg === 'loop-session-1'), drops fix(workflows): interactive loop resume uses fresh session on first iteration #1923's regression test, and reverts the loop-nodes.md note.
• Scope boundary: fix(workflows): fail loudly on SDK isError results in DAG and loop nodes #1291's fail-loud isError handling, fresh_context: true loops, non-interactive loops, and persist_session loops are untouched. Does not attempt to fix the original fix: interactive loop resume crashes with error_during_execution (stale session) #1208 crash (separate work).

Provenance

Takeover of #2005 by @ianstantiate (commit authorship preserved), rebased onto current dev and re-validated. Supersedes #2005. Thanks @ianstantiate.

Validation Evidence

Rebased onto current dev (dag-executor.ts has changed since the original PR — verified the revert target needsFreshSession is intact and the change still correct):

bun --filter @archon/workflows type-check   # ✅ exit 0
bun test packages/workflows/src/dag-executor.test.ts   # ✅ 286 pass / 0 fail

The reverted dag-executor.test.ts passes alongside the resume/resumed tests added by #1842 (no interaction). Net diff: +5/−93 across 3 files.

Security Impact

• New permissions/capabilities? No. New network calls? No. Secrets handling changed? No. FS scope changed? No.
• Behavior revert in the workflow loop executor; no security surface touched.

Compatibility / Migration

• Backward compatible — restores behavior shipped in the latest tagged release; fix(workflows): interactive loop resume uses fresh session on first iteration #1923's behavior was dev-only/unreleased. No config/env/DB changes.

Side Effects / Blast Radius

• Affects executeLoopNode only — any interactive: true loop that resumes after a gate. Environments that genuinely hit the unconfirmed fix: interactive loop resume crashes with error_during_execution (stale session) #1208 error_during_execution will again attempt a resume on the first post-gate iteration; with fix(workflows): fail loudly on SDK isError results in DAG and loop nodes #1291 in place this now fails loudly with the real SDK errors[] rather than masking it.

Rollback Plan

• Revert this PR's merge commit (+5/−93) to re-apply fix(workflows): interactive loop resume uses fresh session on first iteration #1923's fresh-on-resume behavior. No flags/config. Stopgap for any affected loop: set fresh_context: true.

Linked Issues

Closes #2004
Supersedes #2005
Related #1208, #1291, #1923

Summary by CodeRabbit

• Bug Fixes

  • Resumed interactive loops now continue with the previous session on the first resumed iteration, instead of always starting a fresh one.
  • This helps preserve context across approvals and reduces unexpected resets during loop execution.

• Documentation

  • Simplified the loop guide to reflect the updated behavior for fresh context on the first iteration.

[coderabbitai]

📝 Walkthrough

Walkthrough

The loop executor now reuses the stored gate session ID on the first resumed interactive iteration unless fresh_context or the first overall iteration requires a fresh session. The matching test expectation and fresh_context docs were updated.

Changes

Interactive loop resume session reuse

Layer / File(s)	Summary
Session threading and expectations packages/workflows/src/dag-executor.ts, packages/workflows/src/dag-executor.test.ts, packages/docs-web/src/content/docs/guides/loop-nodes.md	executeLoopNode now keeps the stored gate session ID on the first resumed interactive iteration; dag-executor.test.ts updates the resumed sendQuery expectation, and the loop-nodes guide removes the extra freshness note.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Possibly related PRs

• coleam00/Archon#1923: Reverses the fresh-session behavior for resumed interactive loops in dag-executor.ts and updates the same resume-session test path.
• coleam00/Archon#1367: Also changes interactive loop resume behavior in executeLoopNode and dag-executor.test.ts, with related session-handling assertions.

Poem

I hopped through loops with ears held high,
The gate kept whispering, “hold your thread tight.”
First steps stay fresh, then onward we spin,
With stored-session carrots tucked safely in.
🐇✨ Hop, hop—context wins.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly states the workflows fix and the revert of #1923, matching the main change.
Description check	✅ Passed	The description covers summary, scope boundary, validation, compatibility, rollback, and linked issues, with only optional template sections omitted.
Linked Issues check	✅ Passed	The PR restores session continuity after interactive gates, preserves #1291 behavior, and stays within the #2004 scope.
Out of Scope Changes check	✅ Passed	The code, tests, and docs all support the interactive-loop session revert and no unrelated changes stand out.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/loop-session-continuity

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@packages/docs-web/src/content/docs/guides/loop-nodes.md`:
- Line 135: Clarify the wording in the loop-nodes guide so “first iteration” is
explicitly the loop’s initial iteration, not the first run after a resume.
Update the relevant sentence in the docs content to reference the initial loop
iteration (for example, by naming the first pass or `i === 1`) so readers don’t
misinterpret the behavior of resumed interactive loops.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 16eed41d-8341-4092-824f-230cbf38d376

📥 Commits

Reviewing files that changed from the base of the PR and between a159e1a and 046eb46.

📒 Files selected for processing (3)

• packages/docs-web/src/content/docs/guides/loop-nodes.md
• packages/workflows/src/dag-executor.test.ts
• packages/workflows/src/dag-executor.ts

[coderabbitai]

📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win

Clarify that this means the loop’s initial iteration.

“First iteration” is a bit ambiguous now that resumed interactive loops reuse the stored session. Calling out the initial loop iteration (or i === 1) would avoid readers interpreting this as “first iteration after resume.”

Suggested wording

-The first iteration is always fresh regardless of this setting.
+The loop's initial iteration (`i === 1`) is always fresh regardless of this setting.

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	The first iteration is always fresh regardless of this setting.
	The loop's initial iteration (`i === 1`) is always fresh regardless of this setting.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@packages/docs-web/src/content/docs/guides/loop-nodes.md` at line 135, Clarify
the wording in the loop-nodes guide so “first iteration” is explicitly the
loop’s initial iteration, not the first run after a resume. Update the relevant
sentence in the docs content to reference the initial loop iteration (for
example, by naming the first pass or `i === 1`) so readers don’t misinterpret
the behavior of resumed interactive loops.