Repository navigation
docs: correct the statements the api no longer matches - #146
Merged
Merged
Conversation
The errors/* unification and platform #131 landed on the backend, and a number of statements here describe behaviour it no longer has. Each was checked against the backend source and, where it could be, against a live backend. Refusals: - a `GET /<collection>/{id}` miss carries `type: .../not-found` now; `ObjectNotFoundExceptionHandler` calls `Problems.notFound()` instead of hand-building the document. That was the last typeless refusal, so `problem_integration`'s `pending` group is empty and its one test moves to `unified` as a regression guard. - a 401 carries a full problem document naming the check that failed. - the MCP double-encoding regression is fixed, so nothing in that suite is red on purpose; same for `test_duplicate_relationship_type_conflicts`, which is a 409 now. All stay on as guards. - `geoLocation` on a plain resource and `dataSetId` on a DATASET/POLICY are 400s rather than silent drops, and a duplicate `externalId` on `/resources/create` is a clean 409 rather than a constraint violation. Reads and filters: - `/functions/byids`, `/filter` and `/search` exist; the SDK has not wired them, which is a different statement from the api lacking them. - graph reads carry `metadata`; `/datasets/filter` pages; `GET /events/{id}` is a 404; `/events/search` is an unranked substring match over externalId, description and metadata values, newest first. - a literal `externalId` on the event filter matches case-sensitively, unlike every other pattern list. - an absent event sort is `eventTime` ascending, not "no particular order". Deletes docs/api-coverage.md: a point-in-time audit baselined against a backend and an SDK from before all of this, now wrong in nearly every row — it lists /edges as uncovered, the dataset methods as panicking stubs, and omits /assets entirely. AGENTS.md carries the living per-service contract. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: jgjesdal <jostein@intellistream.ai>
Closed
Base automatically changed from
fix/reenable-label-canonicalisation-test
to
main
September 24, 2026 09:47
olavgg
approved these changes
Sep 24, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The backend's
errors/*unification and platform #131 landed, and a number of statements in this repo describe behaviour it no longer has. Each claim was checked against the backend source indatahub-api, and the load-bearing ones against a live backend.All three "red on purpose" tests are green
Each was written against intended behaviour the api did not yet provide, deliberately red rather than softened to match the bug. All three server-side fixes have landed, so the prose is what is now wrong. The tests stay on as regression guards.
a_missing_id_is_typed_like_every_other_refusaltype"type: .../not-foundmcp_response_is_a_json_objecttest_duplicate_relationship_type_conflictsObjectNotFoundExceptionHandlernow callsProblems.notFound(), soproblem_integration'spendinggroup is empty — its one test moves intounified.Refusals
geoLocationon a plain resource is a 400 unknown field (verified live), not accepted-and-never-echoed — onlyAssetdeclares itdataSetIdon aDATASET/POLICYis a 400 telling you to remove it, not a silent dropexternalIdon/resources/createis a clean 409; the asymmetry with/timeseries/createis goneReads and filters
/functions/byids,/filterand/searchexist — the SDK has not wired them. That is a different statement from "the api lacks them", and the fix is to call them rather than ask for a bigger page.metadata;/datasets/filterpages;GET /events/{id}is a 404;/events/searchis an unranked substring match overexternalId, description and metadata values, newest firstexternalIdon the event filter matches case-sensitively, unlike every other pattern list — event writers hash verbatim where node filters lowercase firstDeletes
docs/api-coverage.mdA point-in-time audit baselined against a backend and SDK from before all of this. It lists
/edgesas 0-covered, the dataset methods as panickingtodo!()stubs,/resources/filteras missing, and omits/assetsentirely — every one of which is implemented today. Nothing links to it. AGENTS.md carries the living per-service contract.Stack, 2 of 4 — based on #145. Reviewable on its own; merge after it.
Docs impact: prose only, no caller-visible change. Worth an issue on
datahub-sdk-docsif any page repeats the "functions have no byids/filter/search" or "by-id 404s are typeless" claims.🤖 Generated with Claude Code