ci: add a temporary registry-auth debug workflow - #29
Merged
Conversation
The registry publish 401s at the edge upload, which authenticates with a hub-identity verifiable presentation — a different auth domain than the ATProto secrets the failure implicates at first glance. This dispatch-only workflow tests each domain alone, printing shapes and HTTP status codes and never values, so the two can be told apart from run output. Delete once publish auth works. Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01SZ4ZdaPo9erkh5yF4eXh3Z
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.
Finding first: the release's 401 is not the ATProto secrets. The stack (
_handleUnauthorized/fromProcessingFailureCause) is dxos'sedge-client, and the failure happens at the bundle upload to the edge registry — which authenticates with a hub-identity verifiable presentation from the client's HALO identity, and the CI client has none.resolveSession(the step that consumesATPROTO_HANDLE/ATPROTO_APP_PASSWORD) runs after the upload and was never reached — the run log shows the vite build output and then the error, with noUploaded:line.This dispatch-only workflow (marked TEMPORARY, delete once publish auth works) separates the two auth domains so each is testable alone:
atproto— secret shape (length / whitespace / leading-@flags, never values),resolveHandlevia the public API, PDS resolution via plc.directory, thencreateSessionreporting HTTP status only. 200 = the secrets are valid.edge— for each edge environment (dev/main/production):GET /registry/plugins(unauthenticated read) and an unauthenticatedPOST /registry/upload, statuses only. Shows which environment the gate lives on and confirms the 401 reproduces without any CLI involved.Nothing writes anywhere; no secret value can appear in output by construction (and Actions masks them besides).
The real question this tees up: how CI should present a hub identity for the upload. The publish code checks
client.halo.identity.get()and uploads unauthenticated when there is none — options are seeding an identity in CI, an edge-side service token, or self-hosted assets (assetBaseUrl) bypassing edge upload entirely. That's an architectural call once the debug run confirms the picture.Generated by Claude Code