Affected: packages/cli/src/daemon/routes/assertion.ts:400-445
Verified against: main @ 13a70642
Summary
The POST /api/assertion/:name/write route accepts {contextGraphId, quads, subGraphName?} and forwards quads to agent.assertion.write() without validating shape. The agent's downstream code does 'graph' in quad on each entry; when entries are strings (e.g. N-Quad lines) that throws a JavaScript TypeError:
{"error":"Cannot use 'in' operator to search for 'graph' in
<urn:s> <urn:p> <urn:o> ."}
The route handler catches it and returns the raw message as a 500. From the integration-author side, the failure looks like an internal server error rather than a request-format problem. There is no public schema for the expected quad shape; we discovered it by reading packages/cli/test/assertion-cli-smoke.test.ts:97-110 and packages/adapter-autoresearch/src/tools.ts.
Repro
curl -s -X POST http://127.0.0.1:9200/api/assertion/test/write \
-H "Authorization: Bearer $(cat ~/.dkg/auth.token)" \
-H "Content-Type: application/json" \
-d '{
"contextGraphId": "<your-cg>",
"quads": ["<urn:s> <urn:p> <urn:o> ."]
}'
# 500 Internal Server Error, "Cannot use 'in' operator..."
Suggested fixes
- Validate the quad shape in the route handler (each entry must be an object with
subject, predicate, object, graph string fields). Return a 400 with a clear message and a one-line example when validation fails.
- Document the expected shape in the route comment block, with an example. The handler comment currently says
{ contextGraphId, quads, subGraphName? } and stops there.
- Optional: accept N-Quad strings as a second supported input format and convert internally. N-Quads are a standard wire format; an HTTP API that accepts SPARQL strings could reasonably accept N-Quads strings too.
Affected:
packages/cli/src/daemon/routes/assertion.ts:400-445Verified against:
main@13a70642Summary
The
POST /api/assertion/:name/writeroute accepts{contextGraphId, quads, subGraphName?}and forwardsquadstoagent.assertion.write()without validating shape. The agent's downstream code does'graph' in quadon each entry; when entries are strings (e.g. N-Quad lines) that throws a JavaScriptTypeError:The route handler catches it and returns the raw message as a 500. From the integration-author side, the failure looks like an internal server error rather than a request-format problem. There is no public schema for the expected quad shape; we discovered it by reading
packages/cli/test/assertion-cli-smoke.test.ts:97-110andpackages/adapter-autoresearch/src/tools.ts.Repro
Suggested fixes
subject,predicate,object,graphstring fields). Return a 400 with a clear message and a one-line example when validation fails.{ contextGraphId, quads, subGraphName? }and stops there.