feat: add GCP Secret Manager OpenFeature provider

[mahpatil]

Summary

• Adds a new OpenFeature provider for GCP Secret Manager that reads feature flags from GCP Secret Manager secrets
• Includes flag caching, value conversion for all OpenFeature types (bool, string, int, double, object), and background polling for updates
• Adds a sample application under samples/gcp-secret-manager-sample/ with setup/teardown scripts

Provider Details

• Package: providers/gcp-secret-manager
• Class: GcpSecretManagerProvider
• Supports all OpenFeature flag types via structured or plain-text secret values
• Configurable poll interval and GCP project settings

Test plan

• Unit tests for FlagCache, FlagValueConverter, and GcpSecretManagerProvider
• Integration test (GcpSecretManagerProviderIntegrationTest) requires a real GCP project — set GCP_PROJECT_ID env var to run
• Sample app: follow samples/gcp-secret-manager-sample/README.md to run end-to-end

[gemini-code-assist]

Code Review

This pull request introduces a new OpenFeature provider for Google Cloud Secret Manager, enabling feature flags to be managed as GCP secrets. The changes include the core provider implementation with caching and value conversion, along with comprehensive unit and integration tests, and a sample application. Feedback suggests adding an initial entry to the new module's CHANGELOG.md, refining the spotbugs-exclusions.xml to only include relevant exclusions, and improving the testability of FlagCache by injecting a Clock instance instead of relying on Instant.now() and Thread.sleep().

[aepfli]

/gemini review

[gemini-code-assist]

Code Review

This pull request introduces a new OpenFeature provider for Google Cloud Secret Manager, enabling feature flags to be stored and managed as secrets. The implementation includes a TTL-based in-memory cache to optimize API usage and a converter to handle various OpenFeature data types. Feedback identifies several improvement opportunities, including fixing duplicate entries in the changelog, addressing a race condition and a potential 'thundering herd' issue in the caching logic, and strengthening input validation for the secret version configuration.

[gemini-code-assist]

The changelog contains duplicate entries for version 0.0.1. Please consolidate the content.

Suggested change

	# Changelog
	# Changelog
	## 0.0.1
	### ✨ New Features
	* Initial release of the GCP Secret Manager OpenFeature provider.
	## 0.0.1
	### ✨ New Features
	* Initial release of the GCP Secret Manager OpenFeature provider.
	# Changelog
	## 0.0.1
	### ✨ New Features
	* Initial release of the GCP Secret Manager OpenFeature provider.

[gemini-code-assist]

The get method has a check-then-act race condition. Although store is a synchronized map, the sequence of get followed by remove is not atomic. Multiple threads could identify an entry as expired and attempt to remove it simultaneously. Synchronizing on the store instance ensures atomicity for this operation.

    Optional<String> get(String key) {
        synchronized (store) {
            CacheEntry entry = store.get(key);
            if (entry == null) {
                return Optional.empty();
            }
            if (entry.isExpired()) {
                store.remove(key);
                return Optional.empty();
            }
            return Optional.of(entry.value);
        }
    }

[gemini-code-assist]

This implementation is susceptible to a 'thundering herd' problem. If multiple threads request an expired or missing flag simultaneously, they will all trigger a call to fetchFromGcp, potentially exhausting GCP Secret Manager quotas. Using a synchronized block with double-checked locking prevents redundant API calls.

Suggested change

	return cache.get(secretName).orElseGet(() -> {
	String value = fetchFromGcp(secretName);
	cache.put(secretName, value);
	return value;
	});
	Optional<String> cached = cache.get(secretName);
	if (cached.isPresent()) {
	return cached.get();
	}
	synchronized (this) {
	return cache.get(secretName).orElseGet(() -> {
	String value = fetchFromGcp(secretName);
	cache.put(secretName, value);
	return value;
	});
	}

[gemini-code-assist]

The validate method should also check that secretVersion is not null or blank, as it is a required parameter for constructing the GCP secret path.

    public void validate() {
        if (projectId == null || projectId.trim().isEmpty()) {
            throw new IllegalArgumentException("GcpSecretManagerProviderOptions: projectId must not be blank");
        }
        if (secretVersion == null || secretVersion.trim().isEmpty()) {
            throw new IllegalArgumentException("GcpSecretManagerProviderOptions: secretVersion must not be blank");
        }
    }

[chrfwow]

Why not Boolean.parseBoolean()?

[chrfwow]

I'd suggest adding a test that lets a cache entry time out while a get operation and an insert operation are concurrently ongoing. This way we can make sure that a removal of a timed out value does not remove the newly added value by accident. Maybe VmLens can help with that (see our existing VmLens tests).

[chrfwow]

Maybe we should also add a test for negative numbers

[chrfwow]

Do we also want to support the exponential format, e.g. 3141.5e-3? We should add tests accordingly

[chrfwow]

When is the provider null?