fix(test): make nakamoto_integrations::clarity_burn_state less flaky

[benjamin-stacks]

This test is extremely flaky in CI, because one of the test contract call transaction is executed in a different tenure than intended.

[codecov]

Codecov Report

❌ Patch coverage is 0% with 13 lines in your changes missing coverage. Please review.
✅ Project coverage is 63.91%. Comparing base (6c76d35) to head (5112289).
⚠️ Report is 2 commits behind head on develop.

Files with missing lines	Patch %	Lines
stacks-node/src/tests/nakamoto_integrations.rs	0.00%	13 Missing ⚠️

❌ Your project status has failed because the head coverage (63.91%) is below the target coverage (80.00%). You can increase the head coverage or adjust the target coverage.

❗ There is a different number of reports uploaded between BASE (6c76d35) and HEAD (5112289). Click for more details.

HEAD has 43 uploads less than BASE

Flag	BASE (6c76d35)	HEAD (5112289)
	108	65

Additional details and impacted files

@@             Coverage Diff              @@
##           develop    #6841       +/-   ##
============================================
- Coverage    79.38%   63.91%   -15.47%     
============================================
  Files          593      593               
  Lines       358295   358302        +7     
============================================
- Hits        284420   229020    -55400     
- Misses       73875   129282    +55407     

Files with missing lines	Coverage Δ
stacks-node/src/tests/nakamoto_integrations.rs	25.16% <0.00%> (+2.25%)	⬆️

... and 384 files with indirect coverage changes

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 6c76d35...5112289. Read the comment docs.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[brice-stacks]

Thanks for looking into this one! This definitely looks like a more reliable check, but I'm curious, where was the extra block coming from? What transaction(s) did it include?

[benjamin-stacks]

Thanks for looking into this one! This definitely looks like a more reliable check, but I'm curious, where was the extra block coming from? What transaction(s) did it include?

The contract call transaction that was added in the previous run. And that previous block was mined with yet another earlier transaction. And so on.

The race condition happened at the beginning of the tenure, presumably because the get_stacks_blocks_processed() saw an increment that was actually caused by the tenure change block (this is a guess, but it seems reasonable because those checks rely on some timing assumptions).

[github-actions]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.