fix: burn-block-height inside of at-block

[jbencin]

Description

Fix burn-block-height keyword inside of at-block context. See hirosystems/clarinet#1615 for details

Applicable issues

• fixes On Simnet, in at-block, burn-block-height returns the highest latest value, not the value on that block hirosystems/clarinet#1615

Additional info (benefits, drawbacks, caveats)

I'm a little unsure of this this part

.or_else(|_| self.get_index_block_header_hash(cur_stacks_height - 1))?

I had to do this so unit tests would pass, but we get the expected behavior in Clarinet:

(define-read-only (get-burn (height uint))
    (let
        (
            (id (unwrap! (get-stacks-block-info? id-header-hash height) (err 1)))
        )
        (at-block id
            (ok { burn-block-height: burn-block-height, stacks-block-height: stacks-block-height })
        )
    )
)

> ::advance_burn_chain_tip 100
new burn height: 101
new stacks height: 101
> ::advance_chain_tip 100
new burn height: 101
new stacks height: 201
> (contract-call? .contract-0 get-burn u1)
(ok { burn-block-height: u1, stacks-block-height: u1 })
> (contract-call? .contract-0 get-burn u100)
(ok { burn-block-height: u100, stacks-block-height: u100 })
> (contract-call? .contract-0 get-burn u101)
(ok { burn-block-height: u101, stacks-block-height: u101 })
> (contract-call? .contract-0 get-burn u102)
(ok { burn-block-height: u101, stacks-block-height: u102 })
> (contract-call? .contract-0 get-burn u200)
(ok { burn-block-height: u101, stacks-block-height: u200 })
> ::advance_burn_chain_tip 1
new burn height: 102
new stacks height: 202
> ::advance_burn_chain_tip 1
new burn height: 103
new stacks height: 203
> (contract-call? .contract-0 get-burn u202)
(ok { burn-block-height: u102, stacks-block-height: u202 })
> (contract-call? .contract-0 get-burn u203)
(err 1)

Checklist

• Test coverage for new or modified code paths
• Changelog is updated
• Required documentation changes (e.g., docs/rpc/openapi.yaml and rpc-endpoints.md for v2 endpoints, event-dispatcher.md for new events)
• New clarity functions have corresponding PR in clarity-benchmarking repo
• New integration test(s) added to bitcoin-tests.yml

[obycode]

NOTE: We need to include this in a release before 3.1 activates, or else it will require an additional hard-fork.

The or_else that @jbencin is concerned about is due to the fact that the info is not written into the database until the first block of the tenure is mined. We ran into a similar situation with the implementation for get-burn-block-info? and decided to just leave it such that it is unable to retrieve burn block info for the current block in the first block of a tenure.

@kantai do you have any thoughts for a better way to handle this?

[kantai]

@kantai do you have any thoughts for a better way to handle this?

Right — I think the best thing to do might be to add an instance variable to the underlying store like “current burn block” — this would be set to the burn view when block processing begins. The at-block call would then handle looking up the burn view at the at-block target, and set the current burn block at that point, resetting it on return.

This would be a bit more complicated, but it would separate the logic for setting burn block height between at block and normal operation.