Repository navigation
refactor!: remove the inert PROJECT_NAME and the auth_diagnostics module - #148
Merged
olavgg merged 2 commits intoSep 30, 2026
Conversation
JosteinGj
force-pushed
the
refactor/remove-inert-config-and-auth-diagnostics
branch
from
September 24, 2026 09:19
aadb203 to
d3cd185
Compare
Two things the SDK carried that no longer do anything. `auth_diagnostics` existed to explain a 401 the api would not: it decoded the `organization` claim of the token just sent and reconstructed which of the validator's branches had rejected it, because the authentication entry point answered with an empty body. It does not any more — a 401 carries a problem document whose `detail` names the failed check, in wording that covers the same five branches. The SDK was appending a near-duplicate of what the server had already said. The `base64` dependency existed only for this and goes with it. The multi-tenant test that asserted on the reconstructed message now asserts on the server's own wording, so it still pins that the explanation survives the whole path from entry point to `ResponseError`. `PROJECT_NAME` was accepted, stored and never read, and the backend has no such concept on either side of the wire — while AGENTS.md and README.md both listed it as a supported variable. A config value that reads as real and affects nothing is worse than an absent one. BREAKING CHANGE: `DataHubConfig::from_vars` loses its `project_name` parameter, as do the `DataHubClient` and `AsyncDataHubClient` constructors in the Python bindings. Callers passing it positionally must drop the argument; callers passing `project_name=` by keyword must remove it. Needs a note in datahub-sdk-docs: the env-var list and the client constructor signatures both mention it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: jgjesdal <jostein@intellistream.ai>
Deleting the `mod auth_diagnostics;` line left its `///` behind, so it bound to the next item and documented the `blocking` module as "Explaining an unexplained 401 from the token the SDK already holds." That would have shipped to docs.rs as the blocking client's description. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: jgjesdal <jostein@intellistream.ai>
JosteinGj
force-pushed
the
chore/remove-dead-code
branch
from
September 24, 2026 09:27
c4507ec to
5cf32f7
Compare
JosteinGj
force-pushed
the
refactor/remove-inert-config-and-auth-diagnostics
branch
from
September 24, 2026 09:27
d3cd185 to
b0df19e
Compare
Closed
olavgg
approved these changes
Sep 30, 2026
olavgg
deleted the
refactor/remove-inert-config-and-auth-diagnostics
branch
September 30, 2026 10:41
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
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.
Two things the SDK carried that no longer do anything.
auth_diagnosticsIt existed to explain a 401 the api would not: it decoded the
organizationclaim of the token just sent and reconstructed which of the validator's five branches had rejected it, because the authentication entry point answered with an empty body.That is no longer true. Verified live against this backend:
SecurityConfig.refuseUnauthenticatedwritesProblems.unauthorized(authenticationFailureDetail(failure)), andOrganizationValidatorsupplies a written reason for every branch — including the ambiguous case this module's headline feature handled. The SDK was appending a near-duplicate of what the server had already said.The
base64dependency existed only for this and goes with it.The multi-tenant test that asserted on the reconstructed message now asserts on the server's own wording, so it still pins that the explanation survives the whole path from entry point to
ResponseError.One caveat kept in AGENTS.md: every entry-point 401 shares the
unauthorizedslug, so the cause lives indetailprose and cannot be branched on bytype. Don't replace this with a slug match — there isn't one.PROJECT_NAMEAccepted, stored, never read — cargo flagged the field as dead. The backend has no such concept on either side of the wire, while AGENTS.md and README.md both listed it as a supported variable. A config value that reads as real and affects nothing is worse than an absent one.
BREAKING CHANGE
DataHubConfig::from_varsloses itsproject_nameparameter, as do theDataHubClientandAsyncDataHubClientconstructors in the Python bindings.project_name=by keyword must remove itpython_tests/test_auth_constructor.pycovers both constructors and passes.Docs event for
datahub-sdk-docs: the env-var list and the client constructor signatures both mentionPROJECT_NAME.Stack, 4 of 4 — based on #147.
Test count drops 262 → 248 here: the 14
auth_failure_testsgo with the module they test.🤖 Generated with Claude Code