Repository navigation
fix(test): stop the Alibaba allowlist test from expiring with the catalog - #11867
Merged
Merged
Conversation
…alog
`Unit Tests (1/8)` went red on 2026-08-28 across every PR and on main, with
nothing changed — the clock had moved past the shipped catalog's expiry:
config/alibaba-free-tier-allowlist.json → "validUntil": "2026-08-27"
isAlibabaFreeTierAllowlistPackValid() compares that against Date.now(), so from
28/08 loadAlibabaFreeTierAllowlistPack() returns null and the old
assert.ok(pack) could never pass again. Refreshing the date would only reschedule
the same break.
Production was never affected: resolveActiveAllowlistPack() falls back to the
embedded list when a pack expires, which is the intended design. The defect was
the test asserting the shipped catalog is currently fresh — a data property, not
a behavioral contract.
The test now writes its own packs to a temp dir with dates it controls, and
pins both halves of the contract:
- inside the validity window, the pack REPLACES the embedded list (anchored on
a model that exists nowhere else, so loading alone cannot satisfy it);
- once expired, the pack is ignored and the embedded list serves.
That second path is what production has been running since 27/08 and had no
coverage at all, which is why the expiry surfaced as a red test rather than as
understood behavior. A third case pins the comparison against an injected
instant, including the no-expiry pack that never goes stale.
Whether the curated free-tier catalog still matches reality — and so deserves a
freshly dated pack — is a data question left to the operator in #11866.
Closes #11866
This was referenced Aug 28, 2026
diegosouzapw
added a commit
that referenced
this pull request
Aug 28, 2026
…e pipeline fixes Brings e4683cd (#11867 Alibaba allowlist time bomb), 09de69e (#11891 config expiry detector), e71be03 (#11893 runner janitor), 9dc8eab (#11895 provenance × self-hosted lint) and f564b64 (#11901 heavy-build lanes). main is already an ancestor of this branch (v3.8.50 sync-back), so the merge is exactly these five commits. # Conflicts: # tests/unit/alibaba-free-tier-allowlist.test.ts
muhamadgalihsaputra
pushed a commit
to niyatna/NiyatnaRoute
that referenced
this pull request
Sep 27, 2026
…alog (diegosouzapw#11867) `Unit Tests (1/8)` went red on 2026-08-28 across every PR and on main, with nothing changed — the clock had moved past the shipped catalog's expiry: config/alibaba-free-tier-allowlist.json → "validUntil": "2026-08-27" isAlibabaFreeTierAllowlistPackValid() compares that against Date.now(), so from 28/08 loadAlibabaFreeTierAllowlistPack() returns null and the old assert.ok(pack) could never pass again. Refreshing the date would only reschedule the same break. Production was never affected: resolveActiveAllowlistPack() falls back to the embedded list when a pack expires, which is the intended design. The defect was the test asserting the shipped catalog is currently fresh — a data property, not a behavioral contract. The test now writes its own packs to a temp dir with dates it controls, and pins both halves of the contract: - inside the validity window, the pack REPLACES the embedded list (anchored on a model that exists nowhere else, so loading alone cannot satisfy it); - once expired, the pack is ignored and the embedded list serves. That second path is what production has been running since 27/08 and had no coverage at all, which is why the expiry surfaced as a red test rather than as understood behavior. A third case pins the comparison against an injected instant, including the no-expiry pack that never goes stale. Whether the curated free-tier catalog still matches reality — and so deserves a freshly dated pack — is a data question left to the operator in diegosouzapw#11866. Closes diegosouzapw#11866
muhamadgalihsaputra
pushed a commit
to niyatna/NiyatnaRoute
that referenced
this pull request
Sep 27, 2026
…e pipeline fixes Brings 342ca95 (diegosouzapw#11867 Alibaba allowlist time bomb), ce53544 (diegosouzapw#11891 config expiry detector), 8b8d84d (diegosouzapw#11893 runner janitor), 9e87941 (diegosouzapw#11895 provenance × self-hosted lint) and 2fe1c30 (diegosouzapw#11901 heavy-build lanes). main is already an ancestor of this branch (v3.8.50 sync-back), so the merge is exactly these five commits. # Conflicts: # tests/unit/alibaba-free-tier-allowlist.test.ts
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
1 participant
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.
Problema
Unit Tests (1/8)ficou vermelho em toda PR e emmaina partir de 2026-08-28, sem ninguém ter mudado nada.config/alibaba-free-tier-allowlist.jsondeclara"validUntil": "2026-08-27". O relógio passou dessa data,loadAlibabaFreeTierAllowlistPack()passou a devolvernull, e oassert.ok(pack)do teste virou impossível de satisfazer.Reproduz local:
Produção nunca quebrou
resolveActiveAllowlistPack()cai na lista embutida quando o pacote expira — comportamento desenhado. O defeito era o teste, que afirmava que o catálogo versionado está fresco hoje. Isso é propriedade de dado, não contrato de comportamento.Renovar a data no JSON não seria conserto: reagendaria a mesma quebra.
O que mudou
O teste agora escreve seus próprios pacotes num diretório temporário, com datas que ele controla, e fixa as duas metades do contrato:
O segundo caminho é o que produção executa desde 27/08 e não tinha cobertura nenhuma — foi por isso que a expiração apareceu como teste vermelho em vez de comportamento entendido.
Um terceiro caso fixa a comparação contra um instante injetado, incluindo o pacote sem expiração, que nunca envelhece sozinho.
Validação
tscsem nenhum erro no arquivo alteradoFica em aberto, para o operador
A lista curada de free-tier da Alibaba está expirada, então o roteamento usa a embutida desde 27/08. Se a curada ainda reflete a realidade, vale publicar um pacote com data nova — decisão de dado, fora do escopo deste conserto.
Closes #11866