You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Root cause (D12): both discovery builders hardcoded {status:'available',
handlerReady:true} for every registered service, so stubs, dev fakes and
fallbacks reported as fully real — agents and the console were misled.
- spec: standardize the self-description marker (resolves OQ#11):
SERVICE_SELF_INFO_KEY ('__serviceInfo') + ServiceSelfInfoSchema +
readServiceSelfInfo(), which also normalizes plugin-dev's legacy
_dev:true to {status:'stub', handlerReady:false}.
- runtime + metadata-protocol: getDiscoveryInfo()/getDiscovery() honor the
marker — stubs report 'stub', fallbacks 'degraded', never 'available'.
- objectql: the deliberate lightweight analytics fallback self-identifies
as degraded (it keeps serving — no /analytics 404; service-analytics
replaces it via replaceService and reports 'available' untouched).
- realtime (concrete D12 instance from #2462): discovery no longer
advertises a /realtime route or websockets:true — service-realtime is an
in-process pub/sub bus, nothing mounts /realtime, so the advertised
route always 404'd. The registered service reports degraded with
handlerReady:false; provider corrected from the nonexistent
'plugin-realtime' to 'service-realtime'. The client SDK is unaffected
(it falls back to the conventional path, which 404s exactly as before).
- docs: update the discovery examples in realtime-protocol.mdx /
http-protocol.mdx to the honest output.
Verified end-to-end: fresh app-crm boot with --preset minimal reports
analytics degraded with the honest message; default preset (real
service-analytics) reports available; no routes.realtime in either.
The console-side consumer update (trust only handlerReady/available)
stays in the coordinated cross-repo window per the issue.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01A1BtxNeUaGmvUYr8FwtUNu
Copy file name to clipboardExpand all lines: content/docs/protocol/kernel/realtime-protocol.mdx
+11-4Lines changed: 11 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -104,7 +104,7 @@ ObjectStack supports two real-time protocols:
104
104
105
105
### Connection Endpoint
106
106
107
-
The discovery endpoint advertises the realtime route when the realtime service is registered:
107
+
The discovery endpoint reports the realtime service honestly (ADR-0076 D12): because the in-process realtime service mounts **no** HTTP/WS surface today, **no `routes.realtime` entry is advertised** — an advertised route with no handler would 404. The service itself appears in `services.realtime` as `degraded` with `handlerReady: false` when registered:
108
108
109
109
```http
110
110
GET /.well-known/objectstack
@@ -114,14 +114,21 @@ GET /.well-known/objectstack
114
114
{
115
115
"routes": {
116
116
"data": "/api/v1/data",
117
-
"metadata": "/api/v1/meta",
118
-
"realtime": "/api/v1/realtime"
117
+
"metadata": "/api/v1/meta"
118
+
},
119
+
"services": {
120
+
"realtime": {
121
+
"enabled": true,
122
+
"status": "degraded",
123
+
"handlerReady": false,
124
+
"message": "In-process event bus only — no HTTP/WS realtime surface is mounted"
125
+
}
119
126
}
120
127
}
121
128
```
122
129
123
130
<Callouttype="info">
124
-
The discovery `routes.realtime` value is an HTTP path (`/api/v1/realtime`), not a `wss://` URL. A WebSocket upgrade endpoint is part of the planned transport (`IRealtimeService.handleUpgrade()`) and is not yet served.
131
+
A WebSocket upgrade endpoint is part of the planned transport (`IRealtimeService.handleUpgrade()`) and is not yet served. When it lands, discovery will advertise `routes.realtime` again — until then clients must treat `services.realtime.handlerReady: false` as "no wire transport" (see #2462).
0 commit comments