fix(session): use parentID instead of timestamp for loop exit condition

[YLRong]

Issue for this PR

Closes #14935

Type of change

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

What does this PR do?

Fixes duplicate assistant responses caused by clock skew between client and server systems.

Problem

When client and server have different system times (clock skew), the prompt loop's exit condition lastUser.id < lastAssistant.id fails because message IDs are timestamp-based. This causes the loop to continue and generate a second assistant response for the same user message.

The issue occurs when:

• Client clock is faster/slower than server clock by 5+ seconds
• Different timezone configurations between client and server
• NTP sync issues on either side

Solution

Replace timestamp-based comparison with explicit parentID relationship check. The assistant message's parentID field already stores the ID of the user message it responds to, making this a more reliable indicator than timestamp comparison.

Changes:

• Modified loop exit condition in packages/opencode/src/session/prompt.ts
• Added parentID check as primary exit condition
• Kept timestamp comparison as fallback for backward compatibility

How did you verify your code works?

I reproduced and verified the fix in my local environment:

1. Setup: OpenChamber 1.9.3 + OpenCode 1.3.17
2. Reproduction: Adjusted server time to be 10 seconds faster than client
3. Before fix: Sending a message produced two different assistant responses
4. After fix: Only one assistant response is generated
5. Additional testing: Also tested with server time 10 seconds slower - works correctly

The fix uses the existing parentID field which is already populated correctly, so no database migration or data changes are needed.

Checklist

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

[github-actions]

This PR doesn't fully meet our contributing guidelines and PR template.

What needs to be fixed:

• PR description is missing required template sections. Please use the PR template.

Please edit this PR description to address the above within 2 hours, or it will be automatically closed.

If you believe this was flagged incorrectly, please let a maintainer know.

[github-actions]

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

I found some related PRs worth investigating:

Potential Related PRs:

1. PR fix(session): use parentID instead of message ID ordering in prompt loop #17010 - "fix(session): use parentID instead of message ID ordering in prompt loop"

   • This appears to be addressing a very similar issue using parentID in the prompt loop, which is the core approach of the current PR.

2. PR fix(opencode): lastUser identification and loop exit condition #11443 - "fix(opencode): lastUser identification and loop exit condition"

   • Directly addresses the same loop exit condition logic that this PR is fixing.

These PRs (especially #17010) may already be addressing the same clock skew issue with parentID checks. You should verify whether:

• PR fix(session): use parentID instead of message ID ordering in prompt loop #17010 was closed/abandoned or if it's still open
• Whether it fully resolves the issue or if this PR is a new attempt
• If there are any differences in approach between them

[YLRong]

Thanks for the automated check! I've reviewed the related PRs mentioned (#17010 and #11443).

Comparison with existing PRs

PR #17010 by @ShenAC-SAC addresses the same core issue with an identical approach using parentID.

Key differences in this PR (#21294):

1. Backward Compatibility: This PR includes a fallback mechanism:

   lastAssistant.parentID === lastUser.id ||
   (!lastAssistant.parentID && lastUser.id < lastAssistant.id)

   This ensures the fix works for messages that may not have parentID set (legacy data or edge cases).

2. Real-world verification: I've tested this fix against the exact scenario described in UI bug: Assistant responses rendered twice/duplicated #14935 with OpenChamber 1.9.3 + OpenCode 1.3.17, where a 10-second clock skew between client and server was causing duplicate responses.

3. Issue reference: This PR specifically references and fixes UI bug: Assistant responses rendered twice/duplicated #14935.

If the maintainers prefer #17010's approach, I'm happy to close this in favor of that PR. Otherwise, the backward compatibility in this PR might be worth considering for safer rollout.

cc: @ShenAC-SAC @khj809

[github-actions]

This pull request has been automatically closed because it was not updated to meet our contributing guidelines within the 2-hour window.

Feel free to open a new pull request that follows our guidelines.