Repository navigation
fix(test): de-flake pipeline-payloads (per-test re-seed + honest reset) - #3893
Conversation
…eset
provider-request-failure-pipeline.test.ts seeded call_log_pipeline_enabled
once in test.before, but afterEach->resetStorage() wipes the DB after every
test. Tests 2-4 therefore depended on the settings read-cache surviving the
wipe; under CI shard load that cache is evicted at unpredictable times, so the
`expected pipeline payloads` assertions flaked (seen on main Coverage Shard 3/8).
TDD: making resetStorage() honest (invalidateDbCache("settings") so the reset
truly mirrors a cold DB) reproduces the failure deterministically (3/4 fail).
Re-seeding the flag in beforeEach instead of before makes all 4 pass — and the
honest reset is kept as a permanent guard against the same stale-cache masking.
Test-only change; no assertion weakened (the reset is strengthened). 4/4 pass
isolated and 0 failures across 5 isolated + 3 concurrent-shard stress runs.
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request addresses test flakiness under CI load in tests/unit/provider-request-failure-pipeline.test.ts by ensuring the settings read-cache is cleared during database resets and changing the setup hook from test.before to test.beforeEach to re-seed settings deterministically. The reviewer suggests calling invalidateDbCache() without arguments to clear all cache scopes (including pricing, connections, and combos) for a more robust reset.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
| // wipe and silently masks the fact that the fresh DB has the default. In CI | ||
| // under load this cache is evicted at unpredictable times, so tests that rely | ||
| // on the stale cache flake. Make the reset honest and deterministic here. | ||
| invalidateDbCache("settings"); |
There was a problem hiding this comment.
Para garantir um reset verdadeiramente completo e robusto do banco de dados entre os testes, é recomendável invalidar todos os escopos do cache de leitura do banco de dados (não apenas o de settings). Chamar invalidateDbCache() sem argumentos limpa as caches de settings, pricing, connections e incrementa a versão de combos, prevenindo futuros flakes intermitentes caso o teste passe a depender de outras tabelas.
invalidateDbCache();
…eset (cheaper-inference#3893) Integrated into release/v3.8.26
Problema (main Coverage Shard 3/8 vermelho)
tests/unit/provider-request-failure-pipeline.test.tssemeavacall_log_pipeline_enabled: trueuma vez (test.before), masafterEach→resetStorage()apaga o DB a cada teste (resetDbInstance+rmSync). Logo os testes 2-4 dependiam de o setting sobreviver ao wipe via cache de leitura. Sob carga do shard no CI, esse cache é evictado em momentos imprevisíveis → re-lê o DB zerado →call_log_pipeline_enabledno default (falsy) →pipelinePayloadsnão é capturado →AssertionError: expected pipeline payloadsintermitente.Confirmado: passa isolado (4/4), mas falhou no
Coverage Shard (3/8)da main (tests 1902, pass 1900).Causa-raiz provada (TDD determinística)
resetStorage()um reset honesto —invalidateDbCache("settings")após oresetDbInstance(espelha um DB frio, como no CI sob carga) → reproduz a falha deterministicamente: 3/4 falham com exatamenteexpected pipeline payloads.beforeEach(nãobefore) → 4/4 passam.O reset honesto fica como guarda permanente contra o mesmo mascaramento por cache stale. Padrão idêntico ao do
chatcore-translation-paths.test.ts(que semeia por-teste e por isso não flaca).Validação
--test-concurrency=4, heap reduzido, com os arquivos contendentesdatabase-settings-maintenance/chatcore-translation-paths/db-detailed-logs).Mudança test-only, nenhuma asserção enfraquecida (o reset foi fortalecido). Não toca produção, não gera versão.