Feature hasn't been suggested before.
Describe the enhancement you want to request
There is currently no way to start (or restart) the sync loop for one specific existing workspace from outside:
POST /sync/start?workspace=<id> does not select a workspace — WorkspaceRoutingQuery routes the whole call into that workspace's runtime, where it is meaningless.- The directory-only form starts loops only for workspaces of the current project with recently active sessions, so a workspace idle for a while never reconnects after a server restart.
- Internally,
startSync returns early while a fiber exists and its status is not error, so a stuck loop cannot be replaced by calling it again.
In practice the only events that start a workspace's sync are its creation and server startup (under the recent-activity condition). A client that finds a persisted workspace disconnected after a restart has no API to reattach it — its options are recreating the workspace or restarting the server.
Request: an explicit control-plane operation, e.g. POST /sync/start accepting a target workspace as a parameter that selects rather than routes, which (re)starts that workspace's sync loop, replacing an existing fiber. This would let clients implement "reconnect this workspace" and self-heal stuck loops without a server restart. Related bug about the loop hanging without a connect timeout: #41315.
Feature hasn't been suggested before.
Describe the enhancement you want to request
There is currently no way to start (or restart) the sync loop for one specific existing workspace from outside:
POST /sync/start?workspace=<id>does not select a workspace —WorkspaceRoutingQueryroutes the whole call into that workspace's runtime, where it is meaningless.startSyncreturns early while a fiber exists and its status is noterror, so a stuck loop cannot be replaced by calling it again.In practice the only events that start a workspace's sync are its creation and server startup (under the recent-activity condition). A client that finds a persisted workspace disconnected after a restart has no API to reattach it — its options are recreating the workspace or restarting the server.
Request: an explicit control-plane operation, e.g.
POST /sync/startaccepting a target workspace as a parameter that selects rather than routes, which (re)starts that workspace's sync loop, replacing an existing fiber. This would let clients implement "reconnect this workspace" and self-heal stuck loops without a server restart. Related bug about the loop hanging without a connect timeout: #41315.