fix: wire Bitbucket App secrets manager, OAuth connect was permanently broken - #555
Conversation
|
Warning Review limit reachedNext included review available in 52 minutes. View limit detailsLimit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Review configuration: ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (2)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
…y broken cmd/levelrail/main.go wired api.WithGitHubAppSecrets and api.WithGitLabAppSecrets into the real server's option list, but the equivalent api.WithBitbucketAppSecrets call was missing, leaving rt.bitbucketAppSecrets nil on every real deployment. Traced the actual runtime impact: PUT /api/v1/bitbucket-app (save OAuth consumer key/ secret) hard-failed with a 501 "requires a master key to be configured" error, and the connect/callback/repo-browsing routes failed the same way. GET /api/v1/bitbucket-app (status) didn't 501 but silently always reported authorized: false regardless of real state. The full Bitbucket App CLI and web UI already existed and were fully wired to these routes, they were completely non-functional in any real deployment. Verified live against a real running instance: PUT /api/v1/bitbucket-app went from 501 to 200, correctly saving and reflecting the connection. New regression test (root_handler_wiring_test.go) calls rootHandler itself, the exact function run() uses, with a real store.DB and secrets.Manager, and asserts none of GitHub/GitLab/Bitbucket App's connect routes return the nil-dependency 501. No prior test could have caught this class of bug: every existing GitHub/GitLab/Bitbucket App test constructs *api.Router directly with the option already applied, never through the real wiring path. Confirmed the test actually catches the bug by reverting the fix and observing only the bitbucket_app_connect subtest fail, with the exact original error.
5b55e26 to
aff50d3
Compare
|



Summary
cmd/levelrail/main.gowiredapi.WithGitHubAppSecretsandapi.WithGitLabAppSecretsinto the real server's option list, but the equivalentapi.WithBitbucketAppSecretscall was missing, leavingrt.bitbucketAppSecretsnil on every real deployment.Traced the actual runtime impact:
PUT /api/v1/bitbucket-app(save OAuth consumer key/secret) hard-failed with a 501 "requires a master key to be configured" error, and the connect/callback/repo-browsing routes failed the same way.GET /api/v1/bitbucket-app(status) didn't 501 but silently always reportedauthorized: falseregardless of real state. The full Bitbucket App CLI and web UI already existed and were fully wired to these routes, they were completely non-functional in any real deployment.Verified live against a real running instance:
PUT /api/v1/bitbucket-appwent from 501 to 200, correctly saving and reflecting the connection.What this does not do
api.WithGiteaAppSecretscall, so this specific bug class doesn't apply there. Expect a trivial textual (not semantic) merge conflict when that branch rebases past this one, since both touch the same three-line region.Test plan
go build ./...,go vet ./...: cleangolangci-lint run ./cmd/levelrail/...: 0 issuesTestRootHandler_GitProviderAppSecretsWired) calls the realrootHandlerwiring path (not a directly-constructed Router), confirmed to actually catch this bug class by reverting the fix and observing the exact original 501 errorPUT /api/v1/bitbucket-appbehavior before and after the fix