Skip to content

Conversation

@davecgh
Copy link
Member

@davecgh davecgh commented Jan 24, 2026

Prior to the introduction of headers-first semantics, all header processing happened in memory and therefore had a smaller set of possible errors, so the error logging for them was purely for the purposes of debug and logged accordingly at the debug level.

However, now that headers-first semantics are in use, the headers are saved to the database which means database corruption is a possible error. As a result, it was observed that database corruption was being hidden behind debug logs when it really shouldn't be.

This resolves that by updating the header processing path to use the same error detection logic as the block processing path to ensure any errors that are not regular rule errors are not hidden behind debug logs and also to explicitly log a critical failure in the event of database corruption.

Prior to the introduction of headers-first semantics, all header
processing happened in memory and therefore had a smaller set of
possible errors, so the error logging for them was purely for the
purposes of debug and logged accordingly at the debug level.

However, now that headers-first semantics are in use, the headers are
saved to the database which means database corruption is a possible
error.  As a result, it was observed that database corruption was being
hidden behind debug logs when it really shouldn't be.

This resolves that by updating the header processing path to use the
same error detection logic as the block processing path to ensure any
errors that are not regular rule errors are not hidden behind debug logs
and also to explicitly log a critical failure in the event of database
corruption.
@davecgh davecgh added this to the 2.2.0 milestone Jan 24, 2026
Copy link
Member

@jrick jrick left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

reads correctly

Copy link
Member

@JoeGruffins JoeGruffins left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see it on the affected device.

2026-01-24 05:49:46.724 [INF] SYNC: Processed 18000 headers in the last 10.23s (progress 10.88%)
2026-01-24 05:49:57.431 [INF] SYNC: Processed 16000 headers in the last 10.71s (progress 11.74%)
2026-01-24 05:50:07.163 [ERR] SYNC: Failed to process block header 0000000000082ad5a01631416de9aeab0417c2c2877174c233e41a21bb800bd3 from peer 31.97.231.224:19108 (outbound): failed to open ldb transaction: leveldb/table: corruption on data-block (pos=288195): checksum mismatch, want=0xa9bfe451 got=0x665a6dcc [file=000383.ldb] -- disconnecting
2026-01-24 05:50:07.163 [ERR] SYNC: Criticial failure: failed to open ldb transaction: leveldb/table: corruption on data-block (pos=288195): checksum mismatch, want=0xa9bfe451 got=0x665a6dcc [file=000383.ldb]
2026-01-24 05:50:07.163 [INF] SYNC: Syncing headers to block height 1834175 from peer 195.49.75.206:19108 (outbound)

@davecgh davecgh merged commit d40dee5 into decred:master Jan 24, 2026
34 checks passed
@davecgh davecgh deleted the netsync_detect_db_corruption_on_headers branch January 24, 2026 05:56
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.

3 participants