Conversation
datahub-platform#120 (errors/9-binary-problem-types) replaces the single datapoint-block-rejected type with invalid-frame, unknown-timeseries, request-too-large, unsupported-media-type, value-type-mismatch, external-id-mismatch and too-many-in-flight. reason, frameIndex, timeseriesIds and statuses are unchanged. Updates the responses example and table, the limits summary and frame caps, and the client retry table. Also fixes a pre-existing error: limits.md said a body over the raw byte cap got datapoint-block-rejected with a reason, and the binary caps table implied a reason; it was always request-too-large with limitBytes and no reason. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: jgjesdal <jostein@intellistream.ai>
datahub-platform#120 (b3412ec0) split the single datapoint-block-rejected type, which answered 400, 404, 413, 415, 422 and 429 depending on the case, into one type per status: invalid-frame, unknown-timeseries, request-too-large, unsupported-media-type, value-type-mismatch, external-id-mismatch and too-many-in-flight. RFC 9457 gives a type one status. The commit before this one takes datapoint-block-rejected out of the responses table and example, the limits summary row and frame-caps prose, and the client retry row. Two facts that table does not carry on its own. request-too-large and unsupported-media-type are the API-wide types rather than this endpoint's, so the same condition answers the same way whichever path produced it, and a client that already handles them needs nothing new. And the retired type is worth naming once: a client matching on datapoint-block-rejected now matches nothing, while reason survives unchanged as the stable sub-code, so one matching on reason keeps working. The Rust SDK reads the two stale-series types off the problem on branch fix/binary-stale-series-typed-problems. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: jgjesdal <jostein@intellistream.ai>
JosteinGj
force-pushed
the
docs/binary-problem-types
branch
from
September 18, 2026 08:12
ef12987 to
4a0a6c4
Compare
A reader counting rows in the table above finds seven, not six, because 422 has two. Name the statuses instead of counting them. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: jgjesdal <jostein@intellistream.ai>
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
1 participant
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.
What changed
IntelliStream-DataHub/datahub-platform#120 stops answering every
POST /timeseries/data/binaryrefusal withdatapoint-block-rejected. Each status now has its own type;reason,frameIndex,timeseriesIdsand the statuses are unchanged.typeinvalid-frameunknown-timeseriesrequest-too-largeunsupported-media-typevalue-type-mismatch/external-id-mismatchtoo-many-in-flightPages
reference/binary-datapoints.md: §Responses intro, JSON example (now the 422external-id-mismatch) and atypecolumn in the status table; caps table row for the compressed body.reference/limits.md: summary table row, §Request body size, §Binary frame caps.reference/client.md: the binary row of the retry table.Pre-existing error fixed
limits.mdsaid a body over the binary endpoint's raw byte cap gotdatapoint-block-rejectedwithreason: "request-too-large". The request-body-size filter has always sentrequest-too-largewithlimitBytesand noreason. The caps table inbinary-datapoints.mdimplied a reason for that row too.Merge after IntelliStream-DataHub/datahub-platform#120 ships; until then these pages would describe types the API does not send yet.
🤖 Generated with Claude Code