Skip to content

Close gaps in the Atlas removal marking tests - #1292

Merged
brharrington merged 1 commit into
Netflix:mainfrom
brharrington:atlas-marking-test-gaps
Sep 8, 2026
Merged

Close gaps in the Atlas removal marking tests#1292
brharrington merged 1 commit into
Netflix:mainfrom
brharrington:atlas-marking-test-gaps

Conversation

@brharrington

Copy link
Copy Markdown
Contributor

Tests only, no production change. Three of the tests added with the Atlas marking in #1288 checked less than their names suggest.

A no-op sweep satisfied the survivor test

meterSurvivingTheCleanupPassIsNotMarked asserted that the meter kept active is present and unmarked — which is also exactly the state a pass that removed nothing produces. It now asserts the other four are gone. Verified: making AtlasRegistry.removeExpiredMeters() a no-op fails it, and did not before.

Nothing covered the replacement for a removed meter

This is the case the reader added in #1290 depends on. SwapMeter.get() now resolves again when isRemoved() is true, so if a lookup ever returned an already-marked instance — a change that recycled removed meters, or reset the map without resetting the flag — every update would resolve forever instead of making progress, at a full registry.counter(id) each time. The existing tests only ever looked at meters that had been removed, never at their replacements.

theReplacementForARemovedMeterIsNotMarked sweeps the counter, confirms the original is marked, re-creates it, and asserts the replacement is a different unmarked instance.

closeMarks read the flag and nothing else

It now also checks the meter is no longer registered after close().

Worth being precise about what that does and does not pin: it is an end-state check. Whether the mark is set after the entry is removed rather than before — the invariant markRemoved() documents, fixed in #1287 — is only observable from inside markRemoved() itself, and stays pinned by RemovableMeterMarkingTest, which records what the registry could find at that moment. I confirmed that reverting closeState() to the mark-then-clear form does not fail this test, so the comment now points at the test that does cover it instead of implying this one does.

Three of the tests added with the Atlas marking in Netflix#1288 checked less
than their names suggest.

meterSurvivingTheCleanupPassIsNotMarked asserted that the meter kept
active is present and unmarked, which is also exactly what a pass that
removed nothing produces. It now asserts the other four are gone, and
fails if the sweep is made a no-op.

Nothing covered the replacement for a removed meter. That is the case
the reader added in Netflix#1290 depends on: if a lookup ever returned an
already marked instance, every update would resolve again forever
instead of making progress. Added a test that the replacement is a
different, unmarked instance.

closeMarks only read the flag, so it said nothing about whether the
meter was still registered afterwards. It now checks that too. The
ordering the flag depends on, that the mark is set after the entry is
gone, is only observable from inside markRemoved() and stays pinned by
RemovableMeterMarkingTest; the comment says so rather than implying this
test covers it.
@brharrington brharrington added this to the 1.10.7 milestone Sep 8, 2026
@brharrington
brharrington merged commit 983af50 into Netflix:main Sep 8, 2026
1 check passed
@brharrington
brharrington deleted the atlas-marking-test-gaps branch September 8, 2026 17:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant