app-server: add filesystem watch support#14533
Conversation
| #[ts(export_to = "v2/")] | ||
| pub struct FsWatchResponse { | ||
| /// Connection-scoped watch identifier used for `fs/unwatch` and `fs/changed`. | ||
| pub watch_id: String, |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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)>?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
makes sense, if it makes the client implementation simpler i am for it
There was a problem hiding this comment.
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, |
There was a problem hiding this comment.
if we do away with watch_id, subscriptions could be keyed off of the watch_path instead?
non-blocking, up to you
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.
b7a8267 to
e8f54ad
Compare
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