Disable LML client limiter in CI to fix metadata-lml suite drain (BS#955)#957
Merged
Conversation
…955) G4 (PR #948 / BS#906) added a module-level Semaphore(5) + TokenBucket(50/min) to apps/backend/services/lml/lml.client.ts as a prod safety net mirroring LML's Discogs ceilings. Under integration's --runInBand the bucket persists across spec files; the full suite triggers > 50 fire-and-forget /lookup calls during earlier suites, draining the bucket. By the time metadata-lml.spec.js runs, every call waits ~1200ms for a token and the proxy test times out at 30s. The unit test author for G4 had already documented this risk (tests/unit/services/lml.client.test.ts:792 sets `LML_CLIENT_RATE_PER_MIN: '60000'` with the comment "effectively no rate cap in tests") but the convention wasn't propagated to either CI environment. CI for this repo has two surfaces that diverged independently: - .github/workflows/test.yml `Start services` env — actual GitHub Actions CI, host node processes - dev_env/docker-compose.yml ci backend env — local `npm run ci:testmock` Both override LML_CLIENT_MAX_CONCURRENT and LML_CLIENT_RATE_PER_MIN to high values so the limiter is effectively a no-op in tests. The source-grep test pins both surfaces against future drift. Verified locally: full integration suite shows `PASS tests/integration/metadata-lml.spec.js` with all 11 tests green, including the six that were failing on CI: - adding a non-library track triggers LML search (was: lookupCalls.length === 0) - artwork_url, streaming, artist_bio, search URLs (was: Received has value: null) - GET /proxy/metadata/album returns enriched metadata (was: 30002 ms timeout) — now 7 ms
This was referenced May 19, 2026
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.
Closes #955
Summary
Semaphore(5)+TokenBucket(50/min)toapps/backend/services/lml/lml.client.tsas a prod safety net mirroring LML's Discogs ceilings. The bucket persists across spec files under--runInBand, drains during the > 50 fire-and-forget/lookupcalls the earlier suites issue, and stalls every later call ~1200ms per token — timing outmetadata-lml.spec.jsat 30s.tests/unit/services/lml.client.test.ts:792-793setsLML_CLIENT_RATE_PER_MIN: '60000'with the comment "effectively no rate cap in tests") but the convention wasn't propagated to either CI environment.LML_CLIENT_MAX_CONCURRENT=10000andLML_CLIENT_RATE_PER_MIN=60000in both CI surfaces —.github/workflows/test.yml'sStart servicesenv block (actual GHA CI, host node processes) anddev_env/docker-compose.yml'sbackendci-profile service (localnpm run ci:testmock). A source-grep unit test pins both surfaces against future drift.Test plan
npm run test:unit -- --testPathPatterns=lml-limiter-test-env— 4/4 green (pins both surfaces).npm run typecheck,npm run lint,npm run format:check— all clean.PASS tests/integration/metadata-lml.spec.js, 11/11 tests green including the six that were failing on CI:adding a non-library track triggers LML search— waslookupCalls.length === 0artwork_url,streaming URLs,artist bio,search URLs— wereReceived has value: nullGET /proxy/metadata/album returns enriched metadata— was 30002ms timeout; now 7msIntegration-Testsjob goes green on this PR.Notes
LML_CLIENT_MAX_CONCURRENTandLML_CLIENT_RATE_PER_MINdefaults inlml.client.ts(5 / 50/min) are unchanged. Prod still mirrors LML's Discogs ceiling. This change is test-environment scoped.npm run ci:testmock(docker-compose) and actual GHA CI (host node processes) diverged independently — they don't share an env source. Worth a follow-up to unify or document.