[Nakamoto] getsortition.rs try_handle_request does not actually attempt to return the last winning sortition correctly

[jferrant]

This function should be returning the last sortition with the winning commit. However, note the if statement returns none for the last_sortition_ch when the fetched block snapshot does not contain a winning sortition. Later in the signer we attempt to use this non existent consensus hash to find the last winning soritition which will of course always fail. Update getsortition.rs to properly fetch the last winning sortition. This can either be fixed inside getsortition.rs or in the chainstate.
See the following relevant sections:

stacks-core/stackslib/src/net/api/getsortition.rs

Line 216 in 19f753b

let (miner_pk_hash160, stacks_parent_ch, committed_block_hash, last_sortition_ch) = if !sortition_sn.sortition {

stacks-core/stacks-signer/src/chainstate.rs

Line 359 in 19f753b

let last_sortition_ch = latest_state

[jcnelson]

I can take this

[jcnelson]

So, just a heads up, this is not what the node's API contract of this endpoint is. The API contract is to return data about a specific sortition, given one of a set of possible identifiers for it. If that sortition happens to be empty, then no data will be returned.

But, I can change the node to always return the consensus hash of the last sortition with a winner

[jcnelson]

Here you go. #4939

Can you add test coverage to this and verify that it does what the signer expects it to do?

[jferrant]

Here you go. #4939

Can you add test coverage to this and verify that it does what the signer expects it to do?

Will do!

[blockstack-devops]

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