Description
Every integration suite in host/ pays an unconditional 11-second sleep during setup, and helper code adds more fixed sleeps during tests. With ~10–14 suites running sequentially per CI job, that is ~2–2.5 minutes of pure sleeping in every integration job — and it's the main reason suite setup trips the 30s overhead limit.
Where the sleeps are:
host/integrationbase.go — setupSuite() ends with time.Sleep(cache.DomainCacheRefreshInterval + time.Second) (11s) to wait for registered domains to become visible. DomainCacheRefreshInterval is a hardcoded 10 * time.Second const in common/cache/domainCache.go — there is no config knob.- Same file — the
domainCacheRefresh() helper hard-sleeps 2s; suites that call it mid-test pay 2s per call.
setupSuite() also registers 4–5 domains via sequential RPCs before the sleep.
Proposed changes:
- Make the domain-cache refresh interval injectable for tests (e.g. a test-cluster config field defaulting to the current const, set to ~100–200ms in
host/ setup), or replace the fixed sleep with polling: retry DescribeDomain for each registered domain until visible, with a deadline. Either removes ~11s per suite.
- Apply the same treatment to the 2s sleep in
domainCacheRefresh().
- (Small bonus) issue the 4–5
RegisterDomain calls concurrently.
A good follow-up (separate PR is fine): replace remaining time.Sleep(...) + assert patterns in host/*_test.go with require.Eventually or the existing poller helpers in host/taskpoller.go — fixed sleeps both over-wait when things are fast and flake when CI is slow.
Acceptance criteria: no unconditional multi-second sleeps in host/ suite setup; integration job time drops ~2 min; suite setup reliably under the overhead budget.
Is this a breaking change?
Scope of the feature (server, specific client, all clients)
Test infrastructure (host/, common/cache test hook). No production behavior change — the refresh interval keeps its current default outside tests.
Description
Every integration suite in
host/pays an unconditional 11-second sleep during setup, and helper code adds more fixed sleeps during tests. With ~10–14 suites running sequentially per CI job, that is ~2–2.5 minutes of pure sleeping in every integration job — and it's the main reason suite setup trips the 30s overhead limit.Where the sleeps are:
host/integrationbase.go—setupSuite()ends withtime.Sleep(cache.DomainCacheRefreshInterval + time.Second)(11s) to wait for registered domains to become visible.DomainCacheRefreshIntervalis a hardcoded10 * time.Secondconst incommon/cache/domainCache.go— there is no config knob.domainCacheRefresh()helper hard-sleeps 2s; suites that call it mid-test pay 2s per call.setupSuite()also registers 4–5 domains via sequential RPCs before the sleep.Proposed changes:
host/setup), or replace the fixed sleep with polling: retryDescribeDomainfor each registered domain until visible, with a deadline. Either removes ~11s per suite.domainCacheRefresh().RegisterDomaincalls concurrently.A good follow-up (separate PR is fine): replace remaining
time.Sleep(...)+ assert patterns inhost/*_test.gowithrequire.Eventuallyor the existing poller helpers inhost/taskpoller.go— fixed sleeps both over-wait when things are fast and flake when CI is slow.Acceptance criteria: no unconditional multi-second sleeps in
host/suite setup; integration job time drops ~2 min; suite setup reliably under the overhead budget.Is this a breaking change?
Scope of the feature (server, specific client, all clients)
Test infrastructure (
host/,common/cachetest hook). No production behavior change — the refresh interval keeps its current default outside tests.