cadence-workflow/cadence

Context The cadence-system domain hosts internal system workflows, including the diagnostics workflow started by the frontend DiagnoseWorkflowExecution handler. Its name is defined once as constants.SystemLocalDomainName in common/constants/constants.go, and the worker service creates the domain from that constant at startup in service/worker/service.go (ensureDomainExists). Caveat: the Cassandra schema also seeds this domain directly in schema migrations (schema/cassandra/cadence/versioned/v0.12/system_domain_bootstrap.cql and v0.23/system_domain.cql), so those files also carry the literal name. Other databases (MySQL, Postgres, SQLite) have no such seed and rely entirely on worker provisioning. Any rename of the constant must account for the Cassandra seed as well. Problem service/frontend/api/handler.go (around line 220, DiagnoseWorkflowExecution) hardcodes the string literal "cadence-system" as the target domain for the diagnostics workflow instead of using the shared constant.

Description NewSemaphoreMetadataManager in common/persistence/client/factory.go returns the bare manager implementation with no wrappers at all: result := p.NewSemaphoreMetadataManagerImpl(store, f.logger) return result, nil The core data-path managers (Task, Shard, History, Domain, Execution) are wrapped with errorinjectors → ratelimited → metered. SemaphoreMetadataManager has none of the three — no wrapper files exist for it under common/persistence/wrappers/ and there are no gowrap go:generate directives for it in common/persistence/data_manager_interfaces.go. Consequences: No persistence metrics: semaphore metadata reads/writes emit no latency or error metrics, so failures and slowness in this path are invisible. No rate limiting: semaphore metadata traffic does not honor the datastore QPS quotas. No error injection: the path is skipped by persistence error-injection testing. Fix: add the three gowrap gen go:generate directives for SemaphoreMetadataManager (templates error

Description NewDomainAuditManager in common/persistence/client/factory.go returns the bare manager implementation with no wrappers at all: result := p.NewDomainAuditManagerImpl(store, f.logger, p.NewPayloadSerializer(), f.dc) return result, nil The core data-path managers (Task, Shard, History, Domain, Execution) are wrapped with errorinjectors → ratelimited → metered. DomainAuditManager has none of the three — no wrapper files exist for it under common/persistence/wrappers/ and there are no gowrap go:generate directives for it in common/persistence/data_manager_interfaces.go. Consequences: No persistence metrics: domain audit reads/writes emit no latency or error metrics, so failures and slowness in the audit path are invisible. No rate limiting: audit traffic does not honor the datastore QPS quotas. No error injection: the audit path is skipped by persistence error-injection testing. Domain audit is low-QPS control-plane traffic, so the missing metrics are the biggest practi

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 ~1

Description All 18 jobs in ci-checks.yml start from a cache-less runner and independently rebuild the same test image and recompile the entire Go dependency graph. Measured: ~2.75 min of fixed setup per job, every run (docker build/pull/compose bring-up), plus in-container compilation that is never cached. Specifics: The compose build: blocks in docker/github_actions/docker-compose.yml have no cache_from/cache_to — the Dockerfile's apt-get, pip, and go mod download layers rebuild 18×. actions/setup-go@v5 caches GOMODCACHE/GOCACHE on the host, but compilation happens inside docker compose run containers whose Go dirs are never volume-mounted — the cache step is dead weight. Superseded pushes don't cancel in-flight runs: ci-checks.yml has no concurrency group, so pushing twice quickly runs 36 jobs. ~14 jobs use fetch-depth: 0 (full-history clone) without needing history; no job-level timeout-minutes (GitHub's 360-min default applies if something hangs outside the retry step). Prop