feat(ipc): protocol + Rust transport#404
Conversation
This stack of pull requests is managed by Graphite. Learn more about stacking. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 68ad1bc6c1
ℹ️ 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".
| if wide.starts_with(&unc_prefix) { | ||
| // UNC path — keep canonical form (still has \\?\UNC\ for fspy parity). | ||
| canonical |
There was a problem hiding this comment.
On Windows UNC paths that already exist, canonicalize returns a \\?\UNC\... path and this branch sends that namespaced form to the runner, despite the surrounding comment saying UNC should fall back to the original form. Because the fspy normalization mentioned above only strips the leading \\?\, \\?\UNC\server\share becomes UNC\server\share rather than the original \\server\share, so ignoreInput/ignoreOutput reports for files on network shares can fail to line up with traced paths and remain cached as normal accesses.
Useful? React with 👍 / 👎.
branchseer
force-pushed
the
feat/runner-protocol
branch
2 times, most recently
from
64e2883 to
4ed66c7
Compare
branchseer
changed the title
branchseer
force-pushed
the
feat/runner-protocol
branch
6 times, most recently
from
5e2923c to
6fe2c6d
Compare
Add three new crates that together define the runner-tool IPC: - `vite_task_ipc_shared` — message types + wire format shared by both ends. Spawned tools tell the runner what they read, wrote, or cared about; the runner uses that to decide what to fingerprint in the cache. - `vite_task_server` — async server hosted in the runner. One server instance per task execution. - `vite_task_client` — synchronous blocking client used by spawned tools. The sync API is deliberate: most tools are JS, called one-method-at-a-time, and don't want a runtime imposed on them. The two sides are wired together end-to-end in `vite_task_server/tests/integration.rs`, so this PR is independently reviewable as "does the wire format and transport work correctly?" without depending on runner internals. Design notes: `docs/runner-task-ipc/`. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
branchseer
force-pushed
the
feat/runner-protocol
branch
from
6fe2c6d to
0d670c3
Compare
|
Superseded by restructured 2-PR stack:
|
1 participant
Add three new crates that together define the runner-tool IPC:
vite_task_ipc_shared— message types + wire format shared by bothends. Spawned tools tell the runner what they read, wrote, or cared
about; the runner uses that to decide what to fingerprint in the
cache.
vite_task_server— async server hosted in the runner. One serverinstance per task execution.
vite_task_client— synchronous blocking client used by spawnedtools. The sync API is deliberate: most tools are JS, called
one-method-at-a-time, and don't want a runtime imposed on them.
The two sides are wired together end-to-end in
vite_task_server/tests/integration.rs, so this PR is independentlyreviewable as "does the wire format and transport work correctly?"
without depending on runner internals.
Design notes:
docs/runner-task-ipc/.Co-Authored-By: Claude Opus 4.7 (1M context) noreply@anthropic.com