Skip to content

Darling's deadlock maintenance logs a line when a stage recovers after a failed pass (#5634) - #5637

Merged
erikdarlingdata merged 4 commits into
devfrom
fix/5634-remask-recovery-log
Oct 9, 2026
Merged

erikdarlingdata merged 4 commits into
devfrom
fix/5634-remask-recovery-log

Conversation

@erikdarlingdata

@erikdarlingdata erikdarlingdata commented Oct 9, 2026 •

Copy link
Copy Markdown
Owner

Darling's hourly PostgreSQL deadlock maintenance logs a warning when one of its stages fails a pass, but logged nothing when a later pass of that stage succeeded. An operator who read the warning had no line saying the stage came back. A stage that succeeds after one or more failed passes now logs one information line that names the stage and how many passes had failed. A clean pass with no earlier failure logs nothing new, and the back-off, skip and progress logic are unchanged.

SECTION: Fixed
ENTRY: - Darling's deadlock maintenance logs a line when a stage recovers after a failed pass ([#5637]) - The hourly PostgreSQL deadlock maintenance logged a warning each time one of its stages failed a pass, but nothing when a later pass succeeded, so the last line an operator saw for the stage was the failure. A stage that succeeds after one or more failed passes now logs one information line naming the stage and how many passes had failed. A clean pass with no earlier failure logs nothing new.

Details

  • Darling/PerformanceMonitor.Darling.Service/PgDeadlockRemask.cs, where a clean page resets ConsecutiveFailures: when the count is above 0, one LogInformation line says the stage recovered. It also says how many earlier passes in a row had failed. The line carries the stage name and the count only, never row content.
  • Darling/Darling.Tests/PgDeadlockRemaskTests.cs: two live tests on a local test PostgreSQL. AStageThatRecoversAfterFailures_LogsOneRecoveryLine_WithTheFailureCount fails the alert stage twice by renaming its table away. It then restores the table and expects exactly one recovery line for that stage with the count 2. The two other alert-table stages fail and recover on their own, and each is checked to log at most one line. ACleanPassWithNoEarlierFailure_LogsNoRecoveryLine runs the stages with no failure and expects no recovery line. The test logger now also keeps the information lines.
  • RED: with the production lines reverted, the first test fails ("The collection did not contain any matching items") and the second passes. With them restored, both pass.
  • CHANGELOG.md and docs/changelog/3.10.md carry the entry under 3.10.0 Fixed.

Tests

Darling.Tests on a local PostgreSQL: PgDeadlockRemaskTests Total 26, Failed 0. Then as Total/Failed: *Census* 500/0, *Ratchet* 15/0, *Hygiene* 90/0, *Scrub* 123/0, *Guard* 365/0, *DocComment* 78/0, Stage=Guard 1474/0. 0 build warnings.

Fixes #5634

…r a failed pass (#5634)

A re-mask stage that failed one or more passes and then succeeds now logs one
information line naming the stage and how many passes had failed. A clean pass
with no earlier failure logs nothing new.
Adds the 3.10.0 Fixed entry for the recovery log line.
@erikdarlingdata
erikdarlingdata marked this pull request as ready for review October 9, 2026 14:34
@erikdarlingdata
erikdarlingdata enabled auto-merge (squash) October 9, 2026 14:36
@erikdarlingdata
erikdarlingdata enabled auto-merge (squash) October 9, 2026 15:04
@erikdarlingdata
erikdarlingdata merged commit c5e8af6 into dev Oct 9, 2026
23 of 24 checks passed
@erikdarlingdata
erikdarlingdata deleted the fix/5634-remask-recovery-log branch October 9, 2026 15:17
erikdarlingdata added a commit that referenced this pull request Oct 9, 2026
Keeps both sides of the 3.10.0 Fixed lists and link lists, so the #5626,
#5627 and #5628 lines from this branch and the #5636 and #5637 lines from
dev are all present in CHANGELOG.md and docs/changelog/3.10.md.
erikdarlingdata added a commit that referenced this pull request Oct 9, 2026
Adds the changelog entries for #5626 and #5628 to the 3.10.0 index and to docs/changelog/3.10.md. The #5628 entry cites its own PR. The 3.10.0 date is now 2026-10-09. A second Important entry covers the Windows upgrade stop for installs that ordinary users can write to.

The Important note now names store migrations V158 through V173, as dev is at schema 173. The README gains the shared time range picker, the text column filters and Lite's DuckDB memory limit setting.

The branch merges dev, which brings in the entries for #5636 and #5637, and every entry from both sides is kept. The archive split and census run last. The 3.10.0 census row is 295 entries, and verify and roundtrip both pass. No duplicate section headers and no missing reference links were found in the 3.10.0 entries.

The last changelog splice for 3.10.0, and the README sync.
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