Repository navigation
Conversation
Contributor
Dependency Review✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.Scanned FilesNone |
The follower now sends every new change entry to the packument queue, and the packument processor fetches and processes each package. The follower no longer talks to the registry, the known versions table, or the stager, and needs much less memory. A change request is processed right away. If the registry is behind or has no packument yet, the processor replaces it with a laggy or missing request, which is re-checked as before. Fetch errors retry the change request with the same growing waits. The follower still re-reads its trailing window, so late entries are still found. Entries may be processed more than once; the known versions table keeps versions from being staged twice.
mrgrain
force-pushed
the
mrgrain/feat/npmjs/follower-queues-all-changes
branch
from
October 14, 2026 10:41
b8d54da to
9c1aa23
Compare
This branch has not been deployed
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.
This finishes the split started in #1942. The follower now only reads the changes feed: it sends every new change entry to the packument queue, and the packument processor fetches and processes each package. Until now the follower fetched every packument itself, in large chunks inside a single 5 minute run. That is what made it slow to catch up after an outage, and what made it run out of memory on large backlogs.
The follower still re-reads its trailing window on every run and keeps receipts, so change entries that show up late or out of order are still found. It no longer talks to the registry, the known versions table, the deny and license lists, or the stager. Its role loses those permissions, and its memory goes from 10 GB to 2 GB.
The processor handles a new kind of request,
change. It is processed right away. If the registry already serves the announced revision, the request is done. If the registry is behind or has no packument yet, the processor processes whatever is there and replaces the request with alaggyormissingone, which is checked again exactly as before. If the fetch fails, the change request itself is retried with the same growing waits.Things to look at
Entries can be processed more than once: a run that dies between sending a chunk and saving its receipts sends the chunk again. That is fine, the known versions table keeps versions from being staged twice.
The processor now reads up to 10 batches of 10 at once, so up to 100 packuments in flight. That is about what the follower did before, and what npm saw from us. I have not measured how long a backfill takes this way.
Some metrics now come from the processor instead of the follower, in the same namespace:
NpmJsChangeAge,MetadataFetchFailures,RelevantPackageVersions, and the first sighting of a laggy or missing packument. Because of that,LaggyPackumentsis now a count likeMissingPackuments, not a queue size, andmetricLaggyPackuments()defaults to a sum. A newChangeGiveUpsmetric counts change entries given up on after a day of errors.ChangeCount, which theNoChangesalarm uses, still comes from the follower.The known versions migration now also waits for the processor. Its trigger ids are unchanged, so it does not run again on deployments that already migrated.
Tested with unit tests. Not deployed yet.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license