Repository navigation
Conversation
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Advanced Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
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. Comment |
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
| setState((prev) => prev && !prev.sessions.some((row) => row.id === result.session.id) | ||
| ? { ...prev, sessions: [...prev.sessions, result.session] } : prev); | ||
| const revision = ++conversationRevealSequence.current; | ||
| setAssistantRevealBySession((prev) => new Map(prev).set(result.session.id, revision)); | ||
| return current ?? result.session; |
There was a problem hiding this comment.
🔴 Continued child loses recorded provenance
After continueAssistant succeeds, it discards result.continuation before opening the child. The later publicLease returns only lifecycle, lease, and conversation identity. The seed appears as a failed user task, and the recorded-context panel never renders.
Learn more
The Continue response verifies and returns an AssistantContinuationView, but only result.session enters application state. OpenCodeChat then mounts and performs its normal lifecycle/attach flow. That attach receives publicLease, which has no continuation field, so parseAssistantAttachment produces an attachment without provenance. The chat therefore cannot hide the exact seed or pass provenance into task-state evaluation.
Example: Continue succeeds with a seed saying “Recorded brief: fix checkout.” The HTTP response contains valid provenance, but the opened chat reattaches without it. Instead of showing the recorded-context panel and a paused ready conversation, Studio renders the seed as a normal unanswered user task and reports failure.
Recommended fix: Project the verified durable continuation receipt on every child attachment, including after reload or host restart. Pass that descriptor through AssistantAttachment, and provide the same durable descriptor to record capture so seed exclusion remains consistent in chat and archived task counts. Avoid a transient client-only map because reload is an explicit supported path.
Was this helpful? React with 👍 or 👎 to provide feedback.
1 participant
Primary change type
Problem and motivation
Users need an explicit way to continue from the retained record into a new Assistant without reusing lost native history or duplicating an uncertain request.
Summary and scope
Add Continue in new Assistant from the displayed record and live missing-native-history review. Persist an opaque authority-scoped request tuple across reloads, serialize tab creation, verify exact child/provenance/hash, and adopt only under current navigation/account/bus fences. Show the prepared child paused with recorded context; the first human Send uses normal execution.
Related work
Related issue: https://linear.app/sapiom/issue/SAP-3292
Depends on #1024. Native stack target: main.
Validation
59 distinct browser checks passed (46 Continue/history/End/Terminal plus13 chat regressions), with final15 Continue and2 evidence cases rerun after refinements. Two deliberate tuple/hash mutations were detected and restored. Frontend TypeScript, explicit browser lint, formatting and diff checks passed (2 existing warnings).
Tests and documentation
Desktop/mobile evidence includes retained review, paused recorded context, native-history fallback, actual browser reload with zero automatic recovery, and the first ordinary completed human task. These fixtures are distinct from native/installed evidence. Updated assistant-history.md. Increment:968 changed lines including tests/docs/changeset; SDK pr:size is absent.
Compatibility and release impact
Security
AI assistance
Checklist
Review evidence
These images show disposable browser fixture states before and after an explicit user action, not a historical pre-implementation baseline. They do not establish native execution or an installed activated release.