Skip to content

fix(session): use parent relationship instead of ID ordering for loop exit condition#31945

Open
Bibhuti05 wants to merge 2 commits into
anomalyco:devfrom
Bibhuti05:fix-loop-exit
Open

fix(session): use parent relationship instead of ID ordering for loop exit condition#31945
Bibhuti05 wants to merge 2 commits into
anomalyco:devfrom
Bibhuti05:fix-loop-exit

Conversation

@Bibhuti05

@Bibhuti05 Bibhuti05 commented Jun 11, 2026

Copy link
Copy Markdown

Issue for this PR

Closes #29478

Type of change

  • Bug fix
  • New feature
  • Refactor / code improvement
  • Documentation

What does this PR do?

When a Web client provides its own messageID via the async prompt endpoint, that ID can sort lexicographically after the server-generated assistant ID. The loop exit condition lastUser.id < lastAssistant.id then evaluates false, causing the loop to re-enter and create a duplicate assistant message with the same parentID and identical final-answer text.

The fix replaces lastUser.id < lastAssistant.id with (lastAssistant.parentID === lastUser.id || lastUser.id < lastAssistant.id) at prompt.ts:1168. The primary check uses the explicit parent-child relationship, which is the invariant the loop actually needs. The old ID ordering is kept as a defensive fallback for any legacy data where parentID might be absent.

How did you verify your code works?

Added a regression test in prompt.test.ts that seeds a session with a client-provided user ID that sorts after the assistant ID (the exact condition that triggers the bug), then verifies prompt.loop exits immediately with finish: "stop" and no duplicate assistant is created. All existing loop-exit tests continue to pass.

Screenshots / recordings

N/A — non-UI change.

Checklist

  • I have tested my changes locally
  • I have not included unrelated changes in this PR

… exit condition

Web client-provided user message IDs can sort lexicographically after
server-generated assistant IDs, causing the loop exit condition
lastUser.id < lastAssistant.id to evaluate false and produce duplicate
assistant messages. Replace with lastAssistant.parentID === lastUser.id
as the primary check, keeping the old ID ordering as a fallback for
legacy data where parentID may be absent.

Closes anomalyco#29478
@github-actions github-actions Bot added the needs:compliance This means the issue will auto-close after 2 hours. label Jun 11, 2026
@github-actions

Copy link
Copy Markdown
Contributor

The following comment was made by an LLM, it may be inaccurate:

Potential Duplicate PRs Found

The search revealed several related PRs addressing similar session loop exit condition issues:

  1. PR fix(session): use parentID instead of ID ordering for loop exit condition #30042 - fix(session): use parentID instead of ID ordering for loop exit condition

  2. PR fix(session): use parent link for prompt loop exit #29038 - fix(session): use parent link for prompt loop exit

  3. PR fix(session): use parentID instead of timestamp for loop exit condition #21365 - fix(session): use parentID instead of timestamp for loop exit condition

These PRs all target the same session prompt loop exit logic and parent relationship checks. PR #30042 appears to be the most directly related, as it uses identical language about replacing ID ordering with parentID checks.

@github-actions github-actions Bot removed the needs:compliance This means the issue will auto-close after 2 hours. label Jun 11, 2026
@github-actions

Copy link
Copy Markdown
Contributor

Thanks for updating your PR! It now meets our contributing guidelines. 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Web can persist duplicate final answers when client message IDs sort after assistant IDs

1 participant