Skip to content

app-server: add filesystem watch support#14533

Merged
owenlin0 merged 2 commits intomainfrom
ruslan/app-server-fs-watch
Mar 24, 2026
Merged

app-server: add filesystem watch support#14533
owenlin0 merged 2 commits intomainfrom
ruslan/app-server-fs-watch

Conversation

@euroelessar
Copy link
Copy Markdown
Collaborator

@euroelessar euroelessar commented Mar 13, 2026

Summary

Add the v2 app-server filesystem watch RPCs and notifications, wire them through the message processor, and implement connection-scoped watches with notify-backed change delivery. This also updates the schema fixtures, app-server documentation, and the v2 integration coverage for watch and unwatch behavior.

This allows clients to efficiently watch for filesystem updates, e.g. to react on branch changes.

Testing

  • exercise watch lifecycles for directory changes, atomic file replacement, missing-file targets, and unwatch cleanup

@euroelessar euroelessar requested a review from owenlin0 March 13, 2026 00:04
#[ts(export_to = "v2/")]
pub struct FsWatchResponse {
/// Connection-scoped watch identifier used for `fs/unwatch` and `fs/changed`.
pub watch_id: String,
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

minor: have we considered having the client operate on paths only, instead of having the client have to be concerned with watch IDs? i.e. two fs/watch calls to the same path would be idempotent and still be one subscription

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've given it some thought and it looks like it complicates the unwatching logic a fair bit?
we would need to track "# of watcher per path" on either client or server side, otherwise we may unsubscribe when we didn't intend to yet and stop receiving updates.
wdyt?

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm, why do we need to track # of watchers per path?

if a client operates on paths, then it's either watching a path or not, right? so multiple fs/watch calls to a path will be idempotent. and fs/unwatch will just delete the subscription, if it exists.

wouldn't watch state just be: HashSet<(connection_id, path)>?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

imagine if watchers are dynamic, and are periodically created/destroyed based on use cases
clients will need to track how many watchers do they have per path on their side to avoid prematurely calling fs/unwatch if there is still some interest in the path in some other part of the app

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

makes sense, if it makes the client implementation simpler i am for it

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, I've pushed all the hard deduping/counting/etc logic into core's fs watcher in order to make clients simpler

#[ts(export_to = "v2/")]
pub struct FsChangedNotification {
/// Watch identifier returned by `fs/watch`.
pub watch_id: String,
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if we do away with watch_id, subscriptions could be keyed off of the watch_path instead?

non-blocking, up to you

Base automatically changed from ruslan/app-server-fs-api to main March 13, 2026 21:42
Add the v2 app-server filesystem watch RPCs and notifications, wire them through the message processor, and implement connection-scoped watches with notify-backed change delivery. This also updates the schema fixtures, app-server documentation, and the v2 integration coverage for watch and unwatch behavior.
@euroelessar euroelessar force-pushed the ruslan/app-server-fs-watch branch from b7a8267 to e8f54ad Compare March 24, 2026 19:18
@owenlin0 owenlin0 merged commit 301b17c into main Mar 24, 2026
34 of 36 checks passed
@owenlin0 owenlin0 deleted the ruslan/app-server-fs-watch branch March 24, 2026 22:52
@github-actions github-actions bot locked and limited conversation to collaborators Mar 24, 2026
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants