fix(db): ignore non-finite rate_limited_until writes, preserve null clear - #12788
Merged
diegosouzapw merged 1 commit intoSep 8, 2026
Merged
diegosouzapw merged 1 commit into
diegosouzapw merged 1 commit into
Conversation
maxmad64bis
force-pushed
the
fix/ratelimit-write-guard
branch
2 times, most recently
from
September 5, 2026 10:19
d86ca05 to
324d36f
Compare
maxmad64bis
force-pushed
the
fix/ratelimit-write-guard
branch
from
September 6, 2026 01:23
324d36f to
7ad7013
Compare
diegosouzapw
merged commit Sep 8, 2026
678af2e
into
diegosouzapw:release/v3.8.51
8 of 16 checks passed
diegosouzapw
pushed a commit
that referenced
this pull request
Sep 10, 2026
…ot headroom (#12951) Validado numa worktree combinada com a onda de persistência desta leva sobre `release/v3.8.51`: check-file-size e check-changelog-integrity OK, typecheck:core limpo, check-api-typecheck OK (289). Revalidei o head atual mergeado com o tip: typecheck:core limpo e **36/36** entre `db-rate-limit-guard` e as suítes desta PR. Levantar o cooldown do escopo pai sem deixar os filhos aninhados presos é o miolo — um cooldown órfão em filho é invisível no dashboard e mantém a conexão fora de rota sem explicação. **Nota de coordenação:** o `setConnectionRateLimitUntil` colidiu com o #12788 (guard contra timestamp não-finito ou já expirado), que mergeei nesta mesma onda. Eu tinha resolvido a integração na minha worktree, mas ao empurrar o push foi rejeitado — você já tinha empurrado `441fd44`, `f853ba5` e `af2ed01` com a integração feita, e a sua ordenação é equivalente à minha. Descartei a minha e mantive a sua; o crédito é seu inteiro. Fica o registro de que push rejeitado não é erro leve: se eu tivesse mergeado sem reler, teria levado a branch errada.
muhamadgalihsaputra
pushed a commit
to niyatna/NiyatnaRoute
that referenced
this pull request
Sep 27, 2026
…lear (diegosouzapw#12788) Validado numa worktree combinada com a onda de persistência desta leva sobre `release/v3.8.51`: check-file-size e check-changelog-integrity OK, typecheck:core limpo, check-api-typecheck OK (289, dentro da baseline), 70 testes focados no runner Node e 1 no vitest, todos verdes. Persistir `NaN`/`Infinity` numa coluna TEXT envenena toda leitura futura, e um timestamp já expirado sobrescrevendo uma linha viva é pior que não escrever nada. O guard fundido na cabeça da função cobre os dois sem tocar leitores nem o caminho de clear. Os 6 casos do teste incluem o que mais importa: `null` continua limpando, e uma escrita expirada não derruba um cooldown ativo. Nota: 3 deles falham antes do guard, como você registrou. **Integração:** este arquivo colidiu com o diegosouzapw#12951, que também guarda a cabeça de `setConnectionRateLimitUntil` — lá o `null` vira caminho de clear que também remove os cooldowns filhos do Codex. Os dois compõem: trata-se o `null` primeiro (clear + return), e o seu guard de finitude/expiração passa a valer para os não-nulos. Ambos preservados.
muhamadgalihsaputra
pushed a commit
to niyatna/NiyatnaRoute
that referenced
this pull request
Sep 27, 2026
…ot headroom (diegosouzapw#12951) Validado numa worktree combinada com a onda de persistência desta leva sobre `release/v3.8.51`: check-file-size e check-changelog-integrity OK, typecheck:core limpo, check-api-typecheck OK (289). Revalidei o head atual mergeado com o tip: typecheck:core limpo e **36/36** entre `db-rate-limit-guard` e as suítes desta PR. Levantar o cooldown do escopo pai sem deixar os filhos aninhados presos é o miolo — um cooldown órfão em filho é invisível no dashboard e mantém a conexão fora de rota sem explicação. **Nota de coordenação:** o `setConnectionRateLimitUntil` colidiu com o diegosouzapw#12788 (guard contra timestamp não-finito ou já expirado), que mergeei nesta mesma onda. Eu tinha resolvido a integração na minha worktree, mas ao empurrar o push foi rejeitado — você já tinha empurrado `441fd44`, `f853ba5` e `af2ed01` com a integração feita, e a sua ordenação é equivalente à minha. Descartei a minha e mantive a sua; o crédito é seu inteiro. Fica o registro de que push rejeitado não é erro leve: se eu tivesse mergeado sem reler, teria levado a branch errada.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Rate-limit cooldowns are timestamps in the database, and until now any value got written — including ones that make no sense, like
NaN, or ones already in the past. A stale write could leave a connection looking locked (or unlocked) at the wrong time. Now only future timestamps are stored; anything expired or invalid is quietly skipped, and clearing a cooldown works exactly as before.Related Issues
Validation
npm run lintTests Added Or Updated
tests/unit/db-rate-limit-guard.test.ts(new) — 6 cases:NaNignored, ±Infinityignored, past/0ignored, future writes through,nullclear preserved, expired write doesn't overwrite a live row (6/6 pass; 3 fail before the guard as designed)tests/unitthat callssetConnectionRateLimitUntil—db-providers-crud,db-providers-split,antigravity-429-quota-cooldown,persist-429-cooldown-account-fallback,cooldown-epoch-string-3954,mark-account-unavailable-numeric-epoch-guard(82/82 pass)Coverage Notes
src/lib/db/providers/rateLimit.ts(one fused guard + comment at the head ofsetConnectionRateLimitUntil; readers,markConnectionRateLimitedUntil, andclearConnectionRateLimituntouched). Covered by the new test file; no new branches beyond the guard itself.Reviewer Notes
nullviaclearConnectionRateLimit. If any caller relied on writing the past to "unlock" a row, that pattern now needs an explicit clear (no such caller found in the test suites above).