Skip to content

fix: handle new tenant api key#3929

Merged
sweatybridge merged 1 commit into
developfrom
api-key
Jul 29, 2025
Merged

fix: handle new tenant api key#3929
sweatybridge merged 1 commit into
developfrom
api-key

Conversation

@sweatybridge

@sweatybridge sweatybridge commented Jul 29, 2025

Copy link
Copy Markdown
Contributor

What kind of change does this PR introduce?

Bug fix

What is the new behavior?

CLI should prefer new api key over legacy ones.

Additional context

Add any other context or screenshots.

@coveralls

Copy link
Copy Markdown

Pull Request Test Coverage Report for Build 16590601734

Details

  • 21 of 36 (58.33%) changed or added relevant lines in 3 files are covered.
  • 7 unchanged lines in 2 files lost coverage.
  • Overall coverage decreased (-0.1%) to 55.256%

Changes Missing Coverage Covered Lines Changed/Added Lines %
internal/utils/tenant/client.go 10 25 40.0%
Files with Coverage Reduction New Missed Lines %
internal/storage/rm/rm.go 2 80.61%
internal/gen/keys/keys.go 5 12.9%
Totals Coverage Status
Change from base Build 16589943609: -0.1%
Covered Lines: 6182
Relevant Lines: 11188

💛 - Coveralls

@sweatybridge
sweatybridge merged commit 1cf9098 into develop Jul 29, 2025
14 checks passed
@sweatybridge
sweatybridge deleted the api-key branch July 29, 2025 08:45
avallete added a commit that referenced this pull request May 11, 2026
## Summary

- Removes the 10s `http.Client.Timeout` from `NewServiceGateway` and
`NewKongClient` so streaming storage uploads no longer fail with
`Client.Timeout exceeded while awaiting headers` under load.
- The cap was inherited from the tenant-API health-check client when
`NewServiceGateway` was extracted in #3929; it was never chosen for
storage uploads. The active client for local seed (`newLocalClient` →
`NewKongClient`) carries the same anti-pattern, so both are addressed.
- Connection setup is still bounded by the default transport's dial /
TLS-handshake timeouts, and per-call deadlines continue to flow through
the request `Context`.

Fixes
[CLI-1441](https://linear.app/supabase/issue/CLI-1441/storage-uploads-can-time-out-after-10-seconds).

## Why

`http.Client.Timeout` covers dial + send + waiting for response, so a
single small upload taking >10s for the server to ack would surface as a
hard failure. `supabase seed buckets --linked` already worked because
`newRemoteClient` overrides the gateway client with `http.DefaultClient`
(no timeout); the local path through Kong did not.

## Test plan

- [x] `go test ./internal/utils/tenant/ ./internal/storage/client/
./internal/status/` (all pass)
- [x] `go vet` clean for both touched packages
- [ ] Manual repro: re-run the proxy-delay scenario from the issue and
confirm the upload completes instead of timing out at 10s.

---
_Generated by [Claude
Code](https://claude.ai/code/session_01QFScBK1kF6twDYjraZ2hQm)_

---------

Co-authored-by: Claude <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants