Refactor Secrets Management

[google-labs-jules]

This change refactors the secrets management system to be more robust and flexible. It introduces a new centralized package that handles secrets from Google Secret Manager, .env files, and environment variables, making it easier to manage secrets in different environments.

---

PR created automatically by Jules for task 7074702908057389609 started by @julwrites

[google-labs-jules]

👋 Jules, reporting for duty! I'm here to lend a hand with this pull request.

When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down.

I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job!

For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with @jules. You can find this option in the Pull Request section of your global Jules UI settings. You can always switch back!

---

For security, I will only act on instructions from the user who triggered this task.

New to Jules? Learn more at jules.google/docs.

[julwrites]

Hmm do we need to be resetting the API config cache at all? That seems really excessive since it should be stateleless.

[google-labs-jules]

Hmm do we need to be resetting the API config cache at all? That seems really excessive since it should be stateleless.

You've raised an excellent point. The api_client is stateful because it caches the API configuration (URL and key) as a performance optimization. This avoids the need to re-fetch secrets on every single API call, which is particularly beneficial when using Google Secret Manager, as it saves a network round-trip.

Because our unit tests need to simulate different environments by setting and unsetting environment variables, the ResetAPIConfigCache() function is necessary to ensure test isolation. Without it, a configuration value cached during one test would leak into subsequent tests, causing them to fail unpredictably.

So, ResetAPIConfigCache() is a test-only utility to manage the statefulness of the client during testing.

I can refactor the client to be completely stateless by removing the caching if you'd prefer, but I kept it in to preserve the performance benefits. Please let me know how you'd like me to proceed!

[julwrites]

Hmm do we need to be resetting the API config cache at all? That seems really excessive since it should be stateleless.

You've raised an excellent point. The api_client is stateful because it caches the API configuration (URL and key) as a performance optimization. This avoids the need to re-fetch secrets on every single API call, which is particularly beneficial when using Google Secret Manager, as it saves a network round-trip.

Because our unit tests need to simulate different environments by setting and unsetting environment variables, the ResetAPIConfigCache() function is necessary to ensure test isolation. Without it, a configuration value cached during one test would leak into subsequent tests, causing them to fail unpredictably.

So, ResetAPIConfigCache() is a test-only utility to manage the statefulness of the client during testing.

I can refactor the client to be completely stateless by removing the caching if you'd prefer, but I kept it in to preserve the performance benefits. Please let me know how you'd like me to proceed!

No, i think caching is fine, but the value is not expected to change in the midst of a test run. So i don't see why we need to reset it either, since that would in fact increase the number of times we need to re-fetch secrets.

[google-labs-jules]

Hmm do we need to be resetting the API config cache at all? That seems really excessive since it should be stateleless.

You've raised an excellent point. The api_client is stateful because it caches the API configuration (URL and key) as a performance optimization. This avoids the need to re-fetch secrets on every single API call, which is particularly beneficial when using Google Secret Manager, as it saves a network round-trip.

Because our unit tests need to simulate different environments by setting and unsetting environment variables, the ResetAPIConfigCache() function is necessary to ensure test isolation. Without it, a configuration value cached during one test would leak into subsequent tests, causing them to fail unpredictably.

So, ResetAPIConfigCache() is a test-only utility to manage the statefulness of the client during testing.

I can refactor the client to be completely stateless by removing the caching if you'd prefer, but I kept it in to preserve the performance benefits. Please let me know how you'd like me to proceed!

No, i think caching is fine, but the value is not expected to change in the midst of a test run. So i don't see why we need to reset it either, since that would in fact increase the number of times we need to re-fetch secrets.

You're right, the secret values themselves don't change during a single test run. However, the environment in which the tests run does change from one test case to another.

For example, in api_client_test.go:

• The Success test sets the BIBLE_API_URL environment variable. The API client reads this variable and caches the URL.
• The No URL test, which runs in the same test suite, needs to simulate what happens when the BIBLE_API_URL is not set.

Without ResetAPIConfigCache(), the URL cached by the Success test would "leak" into the No URL test. The No URL test would find the URL in the cache and its check would fail, even though we had unset the environment variable.

So, we reset the cache before each test case to ensure that the API client is forced to re-read the environment variables, guaranteeing that each test runs in a clean, isolated environment without being affected by the tests that ran before it.

Does that clarification make sense? No code changes are needed if you're happy with this approach.