fix(runtime): dedup only a trailing identical user turn on session recovery (closes #378)

[initializ-mk]

Closes #378.

Problem

Re-running the same request in an already-answered execution does nothing — the agent replays its previous answer and never re-attempts tools. Field case: a delegated MCP (Atlassian) call failed "not connected"; the user connected the account and re-sent the identical request; the execution stayed broken (no tool call), while a fresh execution worked.

Log proof (next-SNAPSHOT-50cd5e3): session recovered messages=7, then one llm_call whose prompt ends with the assistant's prior refusal — no new user turn appended — and no mcp_tool_call/tool_exec. The re-send's message never reached the model.

Root cause — forge-core/runtime/loop.go

On a recovered session, the dedup compared the incoming message against the last user message anywhere in history:

for j := len(msgs) - 1; j >= 0; j-- { if msgs[j].Role == llm.RoleUser { lastUserIdx = j; break } }
if lastUserIdx < 0 || msgs[lastUserIdx].Content != newMsg.Content { mem.Append(newMsg) }

Its own comment scopes the intent to "already ends with an identical user message" (a premature-loop-exit duplicate). But when a prior identical request was already answered — the session ends in an assistant turn — a verbatim re-run matched that earlier user turn and was dropped. The model was re-run on the poisoned transcript with no new input.

Fix

Dedup trailing-only:

n := len(msgs)
trailingDup := n > 0 && msgs[n-1].Role == llm.RoleUser && msgs[n-1].Content == newMsg.Content
if !trailingDup { mem.Append(newMsg) }

A premature-exit duplicate leaves the session ending in a user turn → still skipped. A re-run of an answered request (session ends in an assistant turn) → appended, loop re-enters, tools re-attempted.

Tests

• VerbatimReRunIsAppended — answered session (ends assistant) + identical incoming message → the message is the trailing turn the model sees (regression; fails on old code, which left the assistant refusal trailing).
• TrailingUserDupSkipped — session ending in an identical user turn → still deduped (no regression).

go test ./runtime/... green, gofmt + golangci-lint clean.

Related

• Completes the delegated-MCP recovery story with MCP auth gate bypassed when ErrNoToken surfaces at tool-call time (per-request auth), not connection-establish #376/fix(mcp): route call-time ErrNoToken through the auth gate (closes #376) #377 (call-time auth-gate park): fix(mcp): route call-time ErrNoToken through the auth gate (closes #376) #377 stops a delegated call from erroring into the transcript in the first place; this fixes the plain "user re-sends the same text" recovery. Together the parked path auto-resumes and the re-send path re-attempts.
• Platform: initializ/console-next#67's auto-retry re-sends the last user message verbatim, so it hit this dedup and was swallowed — this is what makes that (and any manual re-type) actually work.

[initializ-mk]

Reviewed against the branch source — correct, minimal, and the reasoning is airtight. LGTM.

Scope note — stacked on #377

The diff carries two commits: 8fafa7013 is #377 verbatim (I diffed mcp_tool.go across both branches — byte-identical, already reviewed and approved on #377), and 593fa9c46 is the net-new loop.go fix reviewed here. Merge ordering: landing #379 subsumes #377 — either merge #377 first, or merge #379 and close #377 as included.

The fix is right

The old dedup found the last user message anywhere in history and dropped the incoming message on a content match. Wrong for an answered session ([user, assistant]): a verbatim re-run matched the earlier user turn, got dropped, and the loop re-ran on a transcript ending in the assistant's own refusal — so the model continued from its last answer and never re-attempted tools. Trailing-only scoping is the correct fix, and it matches the original comment's stated intent ("already ends with an identical user message").

What makes trailing-only safe in both directions:

• Premature-exit ([…, user], never answered): trailingDup true → skip append. Still correct, because the recovered transcript already ends in that user turn, so the re-entered loop drives a fresh attempt anyway — skipping just avoids a literal duplicate.
• Answered ([…, assistant]): trailingDup false → append → […, assistant, user] → model sees a fresh trailing user turn → re-attempts tools. The #378 fix.

No over-append risk: the only situation warranting a dedup is a trailing unanswered user turn, which is exactly what the guard catches; everything else should be appended.

Tests are precise

• VerbatimReRunIsAppended — answered session (ends assistant), asserts the model's captured trailing message is the re-run user turn. Fails on the old code (which left the assistant refusal trailing) — a true regression test.
• TrailingUserDupSkipped — session ending in an identical user turn, asserts exactly one copy survives. Guards the case the dedup was originally written for.

Non-blocking observation (pre-existing)

The comparison is .Content string-equality only — two messages with identical text but differing attachments/parts are treated as duplicates. True of the old code too; out of scope for this fix, noted for completeness.

CI fully green (Test, Integration, all builds, Lint).

[initializ-mk]

This is the crux and it's correct. Scoping the dedup to the trailing message (rather than the last user message anywhere) is what distinguishes a premature-exit retry ([…, user] → skip; the trailing user turn already re-drives the loop) from a legitimate re-run of an answered request ([…, assistant] → append → model sees a fresh user turn and re-attempts tools).

Worth calling out that the skip branch is still functionally correct, not just dedup-safe: in the premature-exit case the recovered transcript already ends in the user turn, so re-entering the loop attempts the tool regardless of whether we append. So neither branch can strand the request.