fix(mobile): stop silently swallowing taps on out-of-workspace file links - #7859
fix(mobile): stop silently swallowing taps on out-of-workspace file links#7859Exotic209093 wants to merge 1 commit into
Conversation
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Plus 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 |
| yield* providerService.interruptTurn({ threadId: event.payload.threadId }); | ||
| // Some providers discard their callbacks without emitting a matching | ||
| // resolution event. Close those requests after the interrupt succeeds. | ||
| yield* Effect.forEach(pendingUserInputRequests(thread.activities), ({ requestId, turnId }) => |
There was a problem hiding this comment.
🟡 Medium Layers/ProviderCommandReactor.ts:1267
Interrupting a thread with a pending user-input request appends a duplicate user-input.resolved activity when the adapter already resolves that request during interruptTurn. The scan uses the pre-interruption thread.activities snapshot, so it cannot observe the adapter's resolution; re-read the thread after interruption before scanning pending requests.
🤖 Copy this AI Prompt to have your agent fix this:
In file @apps/server/src/orchestration/Layers/ProviderCommandReactor.ts around line 1267:
Interrupting a thread with a pending user-input request appends a duplicate `user-input.resolved` activity when the adapter already resolves that request during `interruptTurn`. The scan uses the pre-interruption `thread.activities` snapshot, so it cannot observe the adapter's resolution; re-read the thread after interruption before scanning pending requests.
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 6c835d2. Configure here.
| Alert.alert( | ||
| "Can't open this file", | ||
| "It lives outside the project folder, so it isn't available here.", | ||
| ); |
There was a problem hiding this comment.
Alert shown after successful navigation
High Severity
Alert.alert runs after the relativePath check with no else, so every in-workspace file tap still navigates and then shows “Can't open this file.” Only unresolved out-of-workspace paths should trigger the alert.
Reviewed by Cursor Bugbot for commit 6c835d2. Configure here.
There was a problem hiding this comment.
Confirmed and fixed in 0d22d6f - the handler returns right after navigation, so only unresolved out-of-workspace paths trigger the alert.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 6c835d25e3
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| Alert.alert( | ||
| "Can't open this file", | ||
| "It lives outside the project folder, so it isn't available here.", | ||
| ); |
There was a problem hiding this comment.
Return before showing the out-of-workspace alert
For every valid in-workspace file link, the handler navigates to ThreadFile and then falls through to this unconditional alert, so ordinary file taps falsely report that the file is outside the project and leave a modal over the destination. Return after navigation.navigate or place this alert in an else branch.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Yep, real bug. Fixed in 0d22d6f - early return after navigate, alert fires only when the path can't be resolved inside the workspace.
| threadId: event.payload.threadId, | ||
| requestId, | ||
| turnId, | ||
| createdAt: event.payload.createdAt, |
There was a problem hiding this comment.
Timestamp cancellations after the pending request
When an interrupt comes from a remote client whose clock is behind the server, reusing the client-generated event.payload.createdAt can place this cancellation before the provider-generated user-input.requested activity. All pending-input derivations sort by createdAt before applying lifecycle events, so the later-sorted request remains pending after the turn was stopped; stamp the synthetic resolution on the server or otherwise guarantee it orders after the request. This affects the remote and multi-device connection modes explicitly supported by the repository.
AGENTS.md reference: AGENTS.md:L19-L21
Useful? React with 👍 / 👎.
ApprovabilityVerdict: Would Approve Macroscope's review found this PR approvable — Straightforward mobile bug fix that shows an alert when tapping out-of-workspace file links instead of silently ignoring the tap. The initially-identified fall-through issue was fixed in the final commit with an early return after navigation. Not approved because:
Adjust the Minimum Blocking Severity for this repo — including turning it Off — in Settings. You can add or adjust custom eligibility rules. Learn more. |
6c835d2 to
8d09bda
Compare
8d09bda to
0d22d6f
Compare


Markdown file links that point outside the current workspace (e.g. \ile:///C:/temp/preview.png) render on mobile as tappable file links with an icon, but tapping did nothing — no navigation, no feedback.
The tap handler in ThreadFeed already resolved the path against the workspace root and navigated when it matched; it just returned silently otherwise. Now, when the destination can't be resolved inside the workspace, the handler shows an alert explaining the file lives outside the project folder and isn't available on-device. Both tap paths (the custom markdown link renderer and the native markdown text rows) go through this same handler, so one change covers them all. I considered wiring up a real preview via the server's project-scoped readFile RPC or making the renderer drop the tappable styling for unresolvable paths, but both need new machinery (server contract changes or threading workspaceRoot into pure render helpers) for little gain.
Fixes #7798
ox-alpha via opencode
Note
Medium Risk
Interrupt now synthesizes
user-input.resolvedactivities, which can hide still-open prompts if request tracking is wrong. The mobile alert also runs after successful in-workspace navigation because it is not gated on a missing relative path.Overview
Turn interrupt now cancels open user-input requests. After
interruptTurnsucceeds,ProviderCommandReactorwalks thread activities for unresolveduser-input.requesteditems (skipping already resolved or stale-failed ones) and appendsuser-input.resolvedwithcancelled: true. That covers providers that drop callbacks without a matching resolution event. Tests seed a pending request and assert the cancelled activity.Mobile markdown file links that cannot be resolved inside the workspace now show an
Alertinstead of a silent tap. Bug: the alert is not in anelseof therelativePathcheck, so in-workspace file navigation would still pop “Can't open this file.”Reviewed by Cursor Bugbot for commit 6c835d2. Configure here.
Note
Fix silent tap handling on out-of-workspace file links in
ThreadFeedAlert.alertcall in the markdown link press handler in ThreadFeed.tsx when a file-styled link resolves outside the workspace, so the user gets feedback instead of a silent no-op.hreflinks are unaffected, but any existing reliance on the handler running to completion after a file navigation will now stop early.Macroscope summarized 0d22d6f.