Skip to content

Check application height in post-upgrade checks - #69

Draft
qezz wants to merge 1 commit into
mainfrom
check-app-height-in-post
Draft

Check application height in post-upgrade checks#69
qezz wants to merge 1 commit into
mainfrom
check-app-height-in-post

Conversation

@qezz

@qezz qezz commented Aug 21, 2026

Copy link
Copy Markdown
Contributor

Application height is updated after the block is committed and after it is executed/applied.

We need this height to know whether the node actually managed to apply the new block, or whether it failed to do so.

The behavior we saw was: when rolling out a "wrong" version of the software, the node commits a block at height N, but fails to execute it. Blazar happily reports that the height N has been reached, and marks the upgrade as "successful".

That works fine for the most upgrades, e.g. when a new version is released and new upgrade handlers are expected expected to execute properly. When the version is wrong, the upgrade handlers are not found, the execution fails, but Blazar still considers it successful.

This change should prevent this issue from happening.

Application height is updated after the block is committed and after
it is executed/applied.

We need this height to know whether the node actually managed to apply
the new block, or whether it failed to do so.

The behavior we saw was: when rolling out a "wrong" version of the
software, the node commits a block at height `N`, but fails to execute
it. Blazar happily reports that the height `N` has been reached, and
marks the upgrade as "successful".

That works fine for the most upgrades, e.g. when a new version is
released and new upgrade handlers are expected expected to execute
properly.  When the version is wrong, the upgrade handlers are not
found, the execution fails, but Blazar still considers it successful.

This change should prevent this issue from happening.
@qezz

qezz commented Aug 21, 2026

Copy link
Copy Markdown
Contributor Author

interesting, CI reports a race condition data race, but I didn't touch any related stuff. and the golang version seems to be the same as on the previous patch

@qezz

qezz commented Aug 21, 2026

Copy link
Copy Markdown
Contributor Author

here we go

it's not an issue in real code, only in tests, which run in parallel, i.e. it triggers the race condition data race only in tests... which is annoying

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