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
The node-discovery protocol (upstream mozilla-ai/cq#373/#374, tracked for adoption in #270) defines a server-published document at /.well-known/cq-node.json that declares the node's real api_base_url. Discovery-aware SDK/CLI clients probe it instead of guessing addr + /api/v1.
The 8th-Layer L2 currently serves the SPA index.html (HTTP 200, text/html) for /.well-known/cq-node.json — the frontend catch-all intercepts the path. Verified against the engineering L2:
GET https://engineering.8th-layer-corp.8th-layer.ai/.well-known/cq-node.json
→ 200, content-type text/html, body = <!doctype html> … (the SPA shell)
This is the exact failure mode #270's action item #4 anticipated.
Why it matters
The L2 serves its data plane at the root, not under /api/v1 — confirmed: POST /propose works, POST /api/v1/propose 404s. That is a non-default URL shape. The discovery document is the mechanism by which a client learns it. Without a real cq-node.json, an adopted discovery client falls back to addr + /api/v1 and 404s every call against our L2s.
Minimum acceptable interim: 404 the path (don't serve the SPA shell) so discovery clients get the clean fallback. The full fix is to publish the real document.
Applies to all L2s (the cq-directory slug router is itself a split-origin deployment). Coordinate with #270 — when #373 lands upstream, align the document/schema with the merged protocol.
Problem
The node-discovery protocol (upstream
mozilla-ai/cq#373/#374, tracked for adoption in #270) defines a server-published document at/.well-known/cq-node.jsonthat declares the node's realapi_base_url. Discovery-aware SDK/CLI clients probe it instead of guessingaddr + /api/v1.The 8th-Layer L2 currently serves the SPA
index.html(HTTP 200,text/html) for/.well-known/cq-node.json— the frontend catch-all intercepts the path. Verified against the engineering L2:This is the exact failure mode #270's action item #4 anticipated.
Why it matters
/api/v1— confirmed:POST /proposeworks,POST /api/v1/propose404s. That is a non-default URL shape. The discovery document is the mechanism by which a client learns it. Without a realcq-node.json, an adopted discovery client falls back toaddr + /api/v1and 404s every call against our L2s.200-with-HTML response does not trigger the discovery client's clean "404 → fall back toaddr/api/v1" path. The client validates the body against the node-discovery JSON Schema; HTML fails validation and raisesDiscoveryError. So once /8l-cq:reflect emits 3-4 KB of pane output per session even with no hard findings #373/fix(#373): /cq:reflect — make silent-default actually silent #374 are adopted, discovery would break clients against our L2s rather than help them.This is the same SPA-catch-all class of bug as the
/propose-returns-HTML interception.Fix
The L2 (cq-server) should serve a genuine
/.well-known/cq-node.jsonahead of the SPA catch-all, declaring the node's real API base:api_base_url= the L2's root (e.g.https://<slug>.8th-layer-corp.8th-layer.ai), since the data plane lives at root, not/api/v1.api_versionper the protocol schema.schema/node_discovery.jsononce /8l-cq:reflect emits 3-4 KB of pane output per session even with no hard findings #373 merges.Minimum acceptable interim: 404 the path (don't serve the SPA shell) so discovery clients get the clean fallback. The full fix is to publish the real document.
Applies to all L2s (the cq-directory slug router is itself a split-origin deployment). Coordinate with #270 — when #373 lands upstream, align the document/schema with the merged protocol.
Related
[cq-align] upstream cq#373 — node discovery protocol