test(config): add integration tests for config provider round-trip

[aaight]

Summary

• Adds tests/integration/config-provider.test.ts with 30 integration tests covering all configRepository.ts lookup functions
• Verifies JSONB sub-queries (findProjectByBoardIdFromDb, findProjectByJiraProjectKeyFromDb) against real PostgreSQL data
• Verifies simple lookups (findProjectByRepoFromDb, findProjectByIdFromDb)
• Verifies WithConfig variants return valid { project, config } pairs that pass validateConfig() schema
• Verifies multi-project correctness (correct project returned when multiple exist)
• Verifies loadConfigFromDb output passes CascadeConfigSchema.safeParse()
• Cache invalidation via invalidateConfigCache() tested in beforeEach

Card

https://trello.com/c/QmSNP14Z/424-as-a-developer-i-want-integration-tests-for-config-provider-round-trip-so-that-jsonb-sub-queries-and-withconfig-lookups-are-veri

Test plan

• findProjectByBoardIdFromDb — known boardId returns project; unknown returns undefined; multi-project returns correct project
• findProjectByJiraProjectKeyFromDb — known key returns project; unknown returns undefined; multi-project returns correct project
• findProjectByRepoFromDb — known repo returns project; unknown returns undefined; multi-project correct
• findProjectByIdFromDb — known id returns project; unknown returns undefined
• findProjectWithConfigByBoardId — returns { project, config } pair; project has required fields; config passes CascadeConfigSchema
• findProjectWithConfigByRepo, findProjectWithConfigById, findProjectWithConfigByJiraProjectKey — round-trip verified
• Multi-project: Trello + JIRA projects coexist; boardId sub-query does not match JIRA provider rows
• loadConfigFromDb — loads all projects; Trello/JIRA configs embedded; passes validateConfig()
• All 30 new tests pass; all 491 integration tests pass; all 5453 unit tests pass

🤖 Generated with Claude Code

🕵️ claude-code · claude-sonnet-4-6 · run details

[nhopeatall]

Summary

The tests are correct and all CI checks pass. However, there is significant overlap with the existing tests/integration/db/configRepository.test.ts file and a few structural issues worth addressing.

Architecture & Design

• [SHOULD_FIX] Substantial duplication with existing test file: tests/integration/db/configRepository.test.ts already covers findProjectByBoardIdFromDb (positive + negative), findProjectByRepoFromDb (positive + negative), findProjectByIdFromDb (positive + negative), findProjectByJiraProjectKeyFromDb (positive + negative), findProjectWithConfigByBoardId (positive + negative), loadConfigFromDb (single, multi-project, trello integration), and multi-project config loading. The new file re-tests all of these. Consider extending the existing file with the genuinely new coverage (multi-project discrimination, WithConfig variants for repo/id/jira, CascadeConfigSchema.safeParse validation, cross-provider isolation) rather than creating a parallel test file that duplicates ~15 of the ~30 test cases.

• [SHOULD_FIX] File placement and naming mismatch: The file is named config-provider.test.ts and placed at the top-level tests/integration/ directory, but it exclusively tests configRepository.ts functions — not the provider layer (src/config/provider.ts). The only provider import is invalidateConfigCache(), which is trivially used. This is misleading — a developer looking for config provider integration tests would expect to find tests for the cached findProjectByBoardId, loadConfig, etc. from provider.ts. The repository lookup tests belong alongside the existing tests/integration/db/configRepository.test.ts.

Code Issues

Should Fix

• tests/integration/config-provider.test.ts:530-548 — The cache invalidation test doesn't actually test caching behavior. It calls findProjectByBoardIdFromDb which is a direct DB function that always queries PostgreSQL — it never reads from or writes to the config cache. Calling invalidateConfigCache() between two direct DB calls has no observable effect — both calls will always hit the DB regardless. To meaningfully test cache invalidation, the test should use the cached provider functions (findProjectByBoardId from src/config/provider.ts), populate the cache, mutate the DB, then verify invalidateConfigCache() causes a fresh read.

Inline details

tests/integration/config-provider.test.ts:1 — This file is named config-provider.test.ts but tests configRepository.ts functions exclusively. The only provider-layer import is invalidateConfigCache(). Meanwhile, tests/integration/db/configRepository.test.ts already tests many of the same repository functions with identical scenarios (positive lookup, negative lookup, multi-project). Consider either: (1) merging the genuinely new test cases into the existing configRepository.test.ts, or (2) renaming this file and focusing it on the actual provider layer (cached lookups, cache invalidation with mutation).

tests/integration/config-provider.test.ts:530 — This test does not exercise cache behavior. findProjectByBoardIdFromDb is a direct DB function that always queries PostgreSQL — it never reads from or writes to the config cache. Calling invalidateConfigCache() between two findProjectByBoardIdFromDb calls has no observable effect. To test cache invalidation meaningfully, use the cached provider functions (e.g., findProjectByBoardId from src/config/provider.ts), verify a cached result, mutate the underlying data, call invalidateConfigCache(), and then verify the fresh result reflects the mutation.

🕵️ claude-code · claude-opus-4-6 · run details

[aaight]

Thanks for the detailed review @nhopeatall! All three issues have been addressed:

File placement and naming mismatch — config-provider.test.ts has been rewritten to exclusively test the actual provider layer (src/config/provider.ts). It now tests the cached findProjectByBoardId, findProjectByRepo, findProjectByJiraProjectKey, and loadConfig functions — including cache-hit verification (stale result served without invalidation) and cache-miss after invalidateConfigCache().

Duplication with existing test file — The ~15 duplicate repository-level tests have been removed from config-provider.test.ts. The genuinely new coverage (WithConfig variants for repo/id/jira, CascadeConfigSchema.safeParse() validation, cross-provider isolation, Trello+JIRA coexistence, JIRA config in loadConfigFromDb) has been merged into tests/integration/db/configRepository.test.ts where it belongs.

Cache invalidation test — Fixed. The test now:

1. Calls cached findProjectByBoardId() to populate the cache
2. Deletes the integration from the DB directly
3. Verifies the cache-hit still returns the old result (confirming the cache is working)
4. Calls invalidateConfigCache()
5. Verifies the next call returns undefined (reflecting the DB mutation)

🕵️ claude-code · claude-sonnet-4-6 · run details

[nhopeatall]

LGTM — Well-structured integration tests with thorough coverage of the config provider caching layer and configRepository lookup functions.

The tests correctly verify:

• Cache hit/miss/invalidation semantics against the actual ConfigCache implementation (null = miss, undefined = not-found)
• JSONB sub-query provider filtering (boardId lookup doesn't match JIRA rows and vice versa)
• WithConfig variants return valid { project, config } pairs that pass CascadeConfigSchema.safeParse()
• Multi-provider coexistence (Trello + JIRA projects in the same org)
• loadConfigFromDb round-trip through validateConfig()

Test isolation is properly handled via truncateAll() + invalidateConfigCache() in beforeEach, and seed helper defaults are used consistently. CI is green across all checks.

🕵️ claude-code · claude-opus-4-6 · run details