Rename root, api and sdk module paths (imports, go.mod, go_package,
ldflags, build scripts, buf configs) and regenerate protobuf/gateway
code with the project's pinned toolchain. Wire identifiers unchanged.
api gets a local replace for sdk; root/api/sdk require v0.1.0.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
* internal/cmd/commands/server/listener_reload_test.go remove t.Parallel() comment
* internal/cmd/commands/server/worker_initial_upstreams_reload_test.go remove t.Parallel
* internal/cmd/commands/server/worker_tags_reload_test.go wait by polling worker instead of sleep
* internal/daemon/worker/routing_info.go make deep copy in LastRoutingInfoSuccess to avoid race condition
* internal/tests/cluster/parallel/orphaned_connections_test.go raise grace period time to allow test to wait for longer
* improve logging in sequential tests
* move ports around and use t.Cleanup to send shutdown signal to test server
* fix one typo
* do final assert in t.Cleanup instead of defer
* undo t.Cleanup change
* add another signal to force shutdown running servers
* add exit early and increase server start timeout
* tighten workerRPC settings on session tests
* tighten more workerRPC timing
* make gen
* add comment explaining deep copying lastRoutingInfoSuccess
Previously, if one of these tests failed to start their servers before
the timeout, there was a risk that the goroutine started to run
the server would invoke t.Errorf after the test itself had concluded.
Replace t.Errorf with fmt.Printf to avoid the panic, and include
the test name for debugging.
This increases the default rate limits to:
- 1,500 reqs / 30 seconds for list actions in total
- 1,500 reqs / 30 seconds for list actions per IP address
- 150 reqs / 30 seconds for list actions per auth token
And for all other actions:
- 30,000 reqs / 30 seconds for list actions in total
- 30,000 reqs / 30 seconds for list actions per IP address
- 3,000 reqs / 30 seconds for list actions per auth token
This seems to be a reasonable default for a small to medium size cluster
based on some scale testing.
(cherry picked from commit 237c8b6084f42655edaba49055e511163fdf1c53)
Previously this would truncate to the nearest integer, which could
result in clients retrying before the quota has reset, and getting rate
limited again. This also includes an update from go-rate that will round
up when reporting the reset time for the RateLimit header.
Note that in the case of a 503, the Retry-After header was already being
set correctly.
See: https://github.com/hashicorp/go-rate/pull/8
shadowdaoandClaude Sonnet 5.5
aditya2548
Sorawis Nilparuk (Bo)
Johan Brandhorst-Satzkorn
Timothy Messier