Skip to content

Keep a replaced zone readable through a late settle - #381

Merged
NelsonVides merged 2 commits into
mainfrom
fix/replaced-zone-early-drop
Oct 16, 2026
Merged

NelsonVides merged 2 commits into
mainfrom
fix/replaced-zone-early-drop

Conversation

@NelsonVides

@NelsonVides NelsonVides commented Oct 15, 2026 •

Copy link
Copy Markdown
Contributor

Follow-up to #377. When commit_zone/1 or discard_zone/1 gets a zone whose staging entry is gone and whose generation no header names any more, it dropped that generation at once, taking it for one that was dropped before it was ever published. It can also be one that was published and then replaced, by a later commit or by delete_zone/1, whose drop is already scheduled for the end of the grace period because queries that read its header may still be resolving against it, for example while a pipeline stage waits on an upstream lookup. A late discard or commit deleted its records under those queries, which then got NXDOMAIN, the answer the grace period is there to prevent.

  • Only a caller that takes a generation's staging entry drops it at once. Publishing takes that entry first, so taking it proves nothing has published the generation and no lookup can be reading it.
  • Any other drop waits out the grace period, as a replaced generation's does. That still drops whatever was written into a generation that was dropped before it was published, 30 seconds later than before.

Return values are unchanged: committing a zone that was replaced since it was published already returned {error, not_staged}, and its documentation now says so. Discarding or committing a zone that is still live is still a no-op.

🔍 QA

Scenario: a late settle of a replaced zone leaves it readable

  • Run rebar3 ct --suite=test/zones_SUITE --group=cache.
  • Expect replaced_zone_outlives_a_late_settle to pass: after one zone replaces another and a second is deleted, discarding and committing each of them again leaves both resolving through their headers. Against v12.0.0 the replaced one answers NXDOMAIN.

Scenario: a dropped staged zone still loses what was written into it

  • Expect staged_zone_is_dropped_with_its_owner to pass: records written into a zone dropped with its owner are gone once the grace period has passed.

📋 Deployment Pre/Post tasks

  • POST: release v12.0.1 to hex.
  • POST: bump erldnsimple to v12.0.1.

:shipit: Deployment Verification

  • make test passes.

Committing or discarding a zone whose staging entry is gone, and whose
generation no header names any more, dropped that generation at once,
taking it for one that was dropped before it was ever published. It can
also be one that was published and replaced since, by a later commit or
by a delete, whose drop is already scheduled for the end of the grace
period because queries that read its header may still be resolving
against it. A late discard or commit of it deleted its records under
those queries, which then got NXDOMAIN, the answer the grace period is
there to prevent.

Only a caller that takes a generation's staging entry knows that nothing
has published it, so only that caller drops it at once. When the entry
is already gone, the generation is dropped once the grace period has
passed, as a replaced one is, which also drops whatever was written into
a dropped one since.
@NelsonVides NelsonVides self-assigned this Oct 15, 2026
@NelsonVides NelsonVides added the bug Code defect or incorrect behavior label Oct 16, 2026
@NelsonVides
NelsonVides merged commit 88b2f12 into main Oct 16, 2026
9 checks passed
@NelsonVides
NelsonVides deleted the fix/replaced-zone-early-drop branch October 16, 2026 06:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Code defect or incorrect behavior

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant