Fix remote file tree not updating with local file changes#10514
Merged
kevinyang372 merged 2 commits intoMay 8, 2026
Merged
Conversation
kevinyang372
changed the title
Contributor
|
I'm starting a first review of this pull request. You can view the conversation on Warp. I completed the review and no human review was requested for this pull request. Comment Powered by Oz |
moirahuang
approved these changes
May 8, 2026
![oz-for-oss[bot]](https://avatars.githubusercontent.com/in/3450139?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Overview
This PR enables incremental repository metadata updates for the remote server daemon by constructing RepoMetadataModel with incremental emission enabled only in RemoteServerDaemon launch mode.
Concerns
- Manual testing evidence is missing for a user-visible remote file-tree behavior change. Please include screenshots or a screen recording showing a remote SSH file-tree update after a server-side file change, or justify why manual testing is not possible.
Verdict
Found: 0 critical, 1 important, 0 suggestions
Request changes
Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).
Powered by Oz
kevinyang372
deleted the
kevin/initialize-repo-metadata-model-with-incremental-updates
branch
trungtai1805
pushed a commit
to trungtai1805/warp
that referenced
this pull request
May 9, 2026
…#10514) ## Problem The file tree in remote SSH sessions does not update when files change on the server. Cd-ing in and out of the directory restores the correct state. ## Root Cause The daemon process creates its `RepoMetadataModel` with `emit_incremental_updates = false`. `initialize_app()` calls `RepoMetadataModel::new(ctx)` for **all** launch modes, including `RemoteServerDaemon`. The `new()` constructor leaves `emit_incremental_updates` disabled on the local sub-model. When the file system watcher detects changes and `apply_file_tree_mutations` runs, it returns `None` instead of a `RepoMetadataUpdate`, so `IncrementalUpdateReady` is never emitted. The `ServerModel` subscribes to `IncrementalUpdateReady` events to push them to clients, but they never arrive. Cd-ing fixes the issue because `NavigatedToDirectory` triggers a full snapshot push (via `RepositoryUpdated` or directly in the handler), which replaces the entire client-side tree. This has been broken since the initial commit — the `new_with_incremental_updates` constructor existed but was never wired into the daemon initialization path. ## Fix In `initialize_app()`, use `RepoMetadataModel::new_with_incremental_updates(ctx)` when the launch mode is `RemoteServerDaemon`. --- [Oz conversation](https://staging.warp.dev/conversation/c0f4ca93-e310-48aa-afd1-0ccc6b8e384d) | [Plan](https://staging.warp.dev/drive/notebook/ehhdaoqpILmQhzyNRukMbl)
zhangyu1818-bot
pushed a commit
to zhangyu1818/warply
that referenced
this pull request
May 10, 2026
…#10514) ## Problem The file tree in remote SSH sessions does not update when files change on the server. Cd-ing in and out of the directory restores the correct state. ## Root Cause The daemon process creates its `RepoMetadataModel` with `emit_incremental_updates = false`. `initialize_app()` calls `RepoMetadataModel::new(ctx)` for **all** launch modes, including `RemoteServerDaemon`. The `new()` constructor leaves `emit_incremental_updates` disabled on the local sub-model. When the file system watcher detects changes and `apply_file_tree_mutations` runs, it returns `None` instead of a `RepoMetadataUpdate`, so `IncrementalUpdateReady` is never emitted. The `ServerModel` subscribes to `IncrementalUpdateReady` events to push them to clients, but they never arrive. Cd-ing fixes the issue because `NavigatedToDirectory` triggers a full snapshot push (via `RepositoryUpdated` or directly in the handler), which replaces the entire client-side tree. This has been broken since the initial commit — the `new_with_incremental_updates` constructor existed but was never wired into the daemon initialization path. ## Fix In `initialize_app()`, use `RepoMetadataModel::new_with_incremental_updates(ctx)` when the launch mode is `RemoteServerDaemon`. --- [Oz conversation](https://staging.warp.dev/conversation/c0f4ca93-e310-48aa-afd1-0ccc6b8e384d) | [Plan](https://staging.warp.dev/drive/notebook/ehhdaoqpILmQhzyNRukMbl) (cherry picked from commit 1711d59)
tungd
pushed a commit
to tungd/warp
that referenced
this pull request
May 11, 2026
…#10514) ## Problem The file tree in remote SSH sessions does not update when files change on the server. Cd-ing in and out of the directory restores the correct state. ## Root Cause The daemon process creates its `RepoMetadataModel` with `emit_incremental_updates = false`. `initialize_app()` calls `RepoMetadataModel::new(ctx)` for **all** launch modes, including `RemoteServerDaemon`. The `new()` constructor leaves `emit_incremental_updates` disabled on the local sub-model. When the file system watcher detects changes and `apply_file_tree_mutations` runs, it returns `None` instead of a `RepoMetadataUpdate`, so `IncrementalUpdateReady` is never emitted. The `ServerModel` subscribes to `IncrementalUpdateReady` events to push them to clients, but they never arrive. Cd-ing fixes the issue because `NavigatedToDirectory` triggers a full snapshot push (via `RepositoryUpdated` or directly in the handler), which replaces the entire client-side tree. This has been broken since the initial commit — the `new_with_incremental_updates` constructor existed but was never wired into the daemon initialization path. ## Fix In `initialize_app()`, use `RepoMetadataModel::new_with_incremental_updates(ctx)` when the launch mode is `RemoteServerDaemon`. --- [Oz conversation](https://staging.warp.dev/conversation/c0f4ca93-e310-48aa-afd1-0ccc6b8e384d) | [Plan](https://staging.warp.dev/drive/notebook/ehhdaoqpILmQhzyNRukMbl)
cephalonaut
pushed a commit
that referenced
this pull request
May 12, 2026
## Problem The file tree in remote SSH sessions does not update when files change on the server. Cd-ing in and out of the directory restores the correct state. ## Root Cause The daemon process creates its `RepoMetadataModel` with `emit_incremental_updates = false`. `initialize_app()` calls `RepoMetadataModel::new(ctx)` for **all** launch modes, including `RemoteServerDaemon`. The `new()` constructor leaves `emit_incremental_updates` disabled on the local sub-model. When the file system watcher detects changes and `apply_file_tree_mutations` runs, it returns `None` instead of a `RepoMetadataUpdate`, so `IncrementalUpdateReady` is never emitted. The `ServerModel` subscribes to `IncrementalUpdateReady` events to push them to clients, but they never arrive. Cd-ing fixes the issue because `NavigatedToDirectory` triggers a full snapshot push (via `RepositoryUpdated` or directly in the handler), which replaces the entire client-side tree. This has been broken since the initial commit — the `new_with_incremental_updates` constructor existed but was never wired into the daemon initialization path. ## Fix In `initialize_app()`, use `RepoMetadataModel::new_with_incremental_updates(ctx)` when the launch mode is `RemoteServerDaemon`. --- [Oz conversation](https://staging.warp.dev/conversation/c0f4ca93-e310-48aa-afd1-0ccc6b8e384d) | [Plan](https://staging.warp.dev/drive/notebook/ehhdaoqpILmQhzyNRukMbl)
cephalonaut
pushed a commit
that referenced
this pull request
May 12, 2026
## Problem The file tree in remote SSH sessions does not update when files change on the server. Cd-ing in and out of the directory restores the correct state. ## Root Cause The daemon process creates its `RepoMetadataModel` with `emit_incremental_updates = false`. `initialize_app()` calls `RepoMetadataModel::new(ctx)` for **all** launch modes, including `RemoteServerDaemon`. The `new()` constructor leaves `emit_incremental_updates` disabled on the local sub-model. When the file system watcher detects changes and `apply_file_tree_mutations` runs, it returns `None` instead of a `RepoMetadataUpdate`, so `IncrementalUpdateReady` is never emitted. The `ServerModel` subscribes to `IncrementalUpdateReady` events to push them to clients, but they never arrive. Cd-ing fixes the issue because `NavigatedToDirectory` triggers a full snapshot push (via `RepositoryUpdated` or directly in the handler), which replaces the entire client-side tree. This has been broken since the initial commit — the `new_with_incremental_updates` constructor existed but was never wired into the daemon initialization path. ## Fix In `initialize_app()`, use `RepoMetadataModel::new_with_incremental_updates(ctx)` when the launch mode is `RemoteServerDaemon`. --- [Oz conversation](https://staging.warp.dev/conversation/c0f4ca93-e310-48aa-afd1-0ccc6b8e384d) | [Plan](https://staging.warp.dev/drive/notebook/ehhdaoqpILmQhzyNRukMbl)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The file tree in remote SSH sessions does not update when files change on the server. Cd-ing in and out of the directory restores the correct state.
Root Cause
The daemon process creates its
RepoMetadataModelwithemit_incremental_updates = false.initialize_app()callsRepoMetadataModel::new(ctx)for all launch modes, includingRemoteServerDaemon. Thenew()constructor leavesemit_incremental_updatesdisabled on the local sub-model. When the file system watcher detects changes andapply_file_tree_mutationsruns, it returnsNoneinstead of aRepoMetadataUpdate, soIncrementalUpdateReadyis never emitted.The
ServerModelsubscribes toIncrementalUpdateReadyevents to push them to clients, but they never arrive.Cd-ing fixes the issue because
NavigatedToDirectorytriggers a full snapshot push (viaRepositoryUpdatedor directly in the handler), which replaces the entire client-side tree.This has been broken since the initial commit — the
new_with_incremental_updatesconstructor existed but was never wired into the daemon initialization path.Fix
In
initialize_app(), useRepoMetadataModel::new_with_incremental_updates(ctx)when the launch mode isRemoteServerDaemon.Oz conversation | Plan