feat(dynamicconfig): expose operational dynamic config Collection on Resource

[jakobht]

Stacked on top of #8092, which is stacked on #8091. Please review in order: #8091 → #8092 → this PR. Until #8091 and #8092 merge, the diff here will include those commits too.

What changed?

Adds Resource.GetOperationalDynamicConfig() *dynamicconfig.Collection, wrapping the operational configstore client added in #8092 so service code can read operational dynamic config values with the same typed-accessor ergonomics used for the primary dynamic config.

The Collection is always non-nil: when the underlying configstore client is unavailable (persistence layer doesn't support a config store), it is backed by a NopClient so callers get default values rather than having to nil-check. This mirrors the existing fallback for the primary dynamic config client. The cluster-name filter is applied, matching how the primary Collection is constructed.

Why?

Services need a typed entry point to read operational dynamic config (the values written via the upcoming UpdateOperationalDynamicConfig admin endpoint). Exposing it on Resource lets each service consume it the same way it consumes the primary Collection, with no nil-handling boilerplate at the call site.

How did you test it?

• go build ./... clean.
• go test -count=1 -race ./common/resource/... ./common/dynamicconfig/... ./common/persistence/ ./service/history/resource/... ./service/history/handler/... all pass.
• Coverage on new lines: GetOperationalDynamicConfig 100%, newOperationalDynamicConfigCollection 100%.
• Extended TestStartStop to assert the getter returns non-nil even when the underlying store is nil; two focused new tests on newOperationalDynamicConfigCollection (nil-store-falls-back-to-nop and uses-store-when-present).

Potential risks

• Adds one method to the Resource interface and service/history/resource.Resource mock — both regenerated mocks are in the diff. No production code consumes the new Collection yet.
• The no-op fallback hides the "operational store unavailable" condition from consumers reading via the Collection — callers that need to detect this should use GetOperationalConfigStore() (returns nil when unavailable) instead.

Release notes

N/A — preparation for a follow-up feature; no user-visible change.

Documentation Changes

N/A.

[gitar-bot]

💡 Quality: Test helper ignores OperationalConfigStore when building Collection

In resource_test_utils.go, GetOperationalDynamicConfig() always creates a new Collection backed by a NopClient, ignoring the s.OperationalConfigStore field declared on the same struct. This means tests that set OperationalConfigStore to a mock won't observe those values through GetOperationalDynamicConfig(), unlike the production Impl which wires the store into the Collection.

This is minor since no production code consumes the Collection yet, but it could surprise future test authors.

Mirror production behavior: use the mock store when present, fall back to NopClient otherwise.:

// GetOperationalDynamicConfig returns a Collection backed by the OperationalConfigStore if set,
// or a no-op client for tests.
func (s *Test) GetOperationalDynamicConfig() *dynamicconfig.Collection {
	var client dynamicconfig.Client
	if s.OperationalConfigStore != nil {
		client = s.OperationalConfigStore
	} else {
		client = dynamicconfig.NewNopClient()
	}
	return dynamicconfig.NewCollection(client, s.Logger)
}

_{Was this helpful? React with 👍 / 👎}

[gitar-bot]

💡 Quality: Test helper creates new Collection on every call

In resource_test_utils.go, GetOperationalDynamicConfig() creates a new dynamicconfig.Collection backed by NewNopClient() on every invocation. This means:

1. It ignores s.OperationalConfigStore (the previous finding, still valid).
2. It allocates a new Collection per call, so tests that call it multiple times get different instances, which could mask bugs if a test checks identity or caches the reference.

Consider storing the Collection in the Test struct (lazily or eagerly) and, when s.OperationalConfigStore is non-nil, wrapping it just like production code does.

Use OperationalConfigStore when available and allow override via a new field:

// Add field to Test struct:
//   OperationalDynamicConfig *dynamicconfig.Collection

func (s *Test) GetOperationalDynamicConfig() *dynamicconfig.Collection {
	if s.OperationalDynamicConfig != nil {
		return s.OperationalDynamicConfig
	}
	var client dynamicconfig.Client = dynamicconfig.NewNopClient()
	if s.OperationalConfigStore != nil {
		client = s.OperationalConfigStore
	}
	return dynamicconfig.NewCollection(client, s.Logger)
}

_{Was this helpful? React with 👍 / 👎}

[gitar-bot]

CI failed: The test `TestQueryWorkflow_DecisionTaskDispatch_Complete` is failing with a 'query does not exist' error, likely due to a regression in workflow state management introduced by the new dynamic config collection.

Overview

A single test failure was identified in TestEngineSuite during history engine execution, which appears directly related to the configuration changes introduced in this PR.

Failures

TestEngineSuite regression (confidence: medium)

• Type: test
• Affected jobs: 76709126156
• Related to change: yes
• Root cause: The test TestEngineSuite/TestQueryWorkflow_DecisionTaskDispatch_Complete fails with "query does not exist". This indicates a potential regression in how the history engine processes workflow queries or state transitions after the integration of the new operational dynamic config collection.
• Suggested fix: Investigate service/history/engine/engineimpl/history_engine_test.go. Verify if the new dynamic config collection is properly initialized in the test suite and ensure that the state transition logic for decision tasks is not inadvertently cleared or misconfigured by the new operational dynamic config dependency.

Summary

• Change-related failures: 1 test failure in the history engine suite.
• Infrastructure/flaky failures: 0
• Recommended action: Review the initialization of the Collection in the TestEngineSuite and ensure all required query-related dependencies are correctly wired after the structural changes to the Resource object.

Code Review 👍 Approved with suggestions 0 resolved / 2 findings

Exposes the operational dynamic config collection on Resource with a NopClient fallback for seamless consumption. Ensure the resource test helper handles the OperationalConfigStore correctly and avoids re-initializing the Collection on every call.

💡 Quality: Test helper ignores OperationalConfigStore when building Collection

📄 common/resource/resource_test_utils.go:489-491

In resource_test_utils.go, GetOperationalDynamicConfig() always creates a new Collection backed by a NopClient, ignoring the s.OperationalConfigStore field declared on the same struct. This means tests that set OperationalConfigStore to a mock won't observe those values through GetOperationalDynamicConfig(), unlike the production Impl which wires the store into the Collection.

This is minor since no production code consumes the Collection yet, but it could surprise future test authors.

Mirror production behavior: use the mock store when present, fall back to NopClient otherwise.

// GetOperationalDynamicConfig returns a Collection backed by the OperationalConfigStore if set,
// or a no-op client for tests.
func (s *Test) GetOperationalDynamicConfig() *dynamicconfig.Collection {
	var client dynamicconfig.Client
	if s.OperationalConfigStore != nil {
		client = s.OperationalConfigStore
	} else {
		client = dynamicconfig.NewNopClient()
	}
	return dynamicconfig.NewCollection(client, s.Logger)
}

💡 Quality: Test helper creates new Collection on every call

📄 common/resource/resource_test_utils.go:488-491

In resource_test_utils.go, GetOperationalDynamicConfig() creates a new dynamicconfig.Collection backed by NewNopClient() on every invocation. This means:

1. It ignores s.OperationalConfigStore (the previous finding, still valid).
2. It allocates a new Collection per call, so tests that call it multiple times get different instances, which could mask bugs if a test checks identity or caches the reference.

Consider storing the Collection in the Test struct (lazily or eagerly) and, when s.OperationalConfigStore is non-nil, wrapping it just like production code does.

Use OperationalConfigStore when available and allow override via a new field

// Add field to Test struct:
//   OperationalDynamicConfig *dynamicconfig.Collection

func (s *Test) GetOperationalDynamicConfig() *dynamicconfig.Collection {
	if s.OperationalDynamicConfig != nil {
		return s.OperationalDynamicConfig
	}
	var client dynamicconfig.Client = dynamicconfig.NewNopClient()
	if s.OperationalConfigStore != nil {
		client = s.OperationalConfigStore
	}
	return dynamicconfig.NewCollection(client, s.Logger)
}

🤖 Prompt for agents

Code Review: Exposes the operational dynamic config collection on Resource with a NopClient fallback for seamless consumption. Ensure the resource test helper handles the OperationalConfigStore correctly and avoids re-initializing the Collection on every call.

1. 💡 Quality: Test helper ignores OperationalConfigStore when building Collection
   Files: common/resource/resource_test_utils.go:489-491

   In `resource_test_utils.go`, `GetOperationalDynamicConfig()` always creates a new `Collection` backed by a `NopClient`, ignoring the `s.OperationalConfigStore` field declared on the same struct. This means tests that set `OperationalConfigStore` to a mock won't observe those values through `GetOperationalDynamicConfig()`, unlike the production `Impl` which wires the store into the Collection.
   
   This is minor since no production code consumes the Collection yet, but it could surprise future test authors.

   Fix (Mirror production behavior: use the mock store when present, fall back to NopClient otherwise.):
   // GetOperationalDynamicConfig returns a Collection backed by the OperationalConfigStore if set,
   // or a no-op client for tests.
   func (s *Test) GetOperationalDynamicConfig() *dynamicconfig.Collection {
   	var client dynamicconfig.Client
   	if s.OperationalConfigStore != nil {
   		client = s.OperationalConfigStore
   	} else {
   		client = dynamicconfig.NewNopClient()
   	}
   	return dynamicconfig.NewCollection(client, s.Logger)
   }

2. 💡 Quality: Test helper creates new Collection on every call
   Files: common/resource/resource_test_utils.go:488-491

   In `resource_test_utils.go`, `GetOperationalDynamicConfig()` creates a new `dynamicconfig.Collection` backed by `NewNopClient()` on every invocation. This means:
   1. It ignores `s.OperationalConfigStore` (the previous finding, still valid).
   2. It allocates a new Collection per call, so tests that call it multiple times get different instances, which could mask bugs if a test checks identity or caches the reference.
   
   Consider storing the Collection in the `Test` struct (lazily or eagerly) and, when `s.OperationalConfigStore` is non-nil, wrapping it just like production code does.

   Fix (Use OperationalConfigStore when available and allow override via a new field):
   // Add field to Test struct:
   //   OperationalDynamicConfig *dynamicconfig.Collection
   
   func (s *Test) GetOperationalDynamicConfig() *dynamicconfig.Collection {
   	if s.OperationalDynamicConfig != nil {
   		return s.OperationalDynamicConfig
   	}
   	var client dynamicconfig.Client = dynamicconfig.NewNopClient()
   	if s.OperationalConfigStore != nil {
   		client = s.OperationalConfigStore
   	}
   	return dynamicconfig.NewCollection(client, s.Logger)
   }

Rules ⚠️ 1/2 requirements met

Repository Rules

❌ GitHub Issue Linking Requirement: No issue link found in the PR description; add a reference to a cadence-workflow issue (e.g., 'Fixes #1234').

✅ PR Description Quality Standards: The PR description provides substantive technical rationale, testing steps, and context.

_{1 rule not applicable. Show all rules by commenting gitar display:verbose.}

Tip

Comment Gitar fix CI or enable auto-apply: gitar auto-apply:on

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Showing less information.

Comment with these commands to change:

Auto-apply	Compact
gitar auto-apply:on	gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}