starknet_getNonce on block_id=pending fails with starknet-devnet-rs 0.0.6

[0xknwn]

Describe the bug (observed vs expected behavior)

I am starting starknet-devnet-rs with the latest 0.0.6 (I tried both from docker and a cargo install) with --seed=0 and when I run a getNonce on the account that is publicized as available with block_id = pending. That is the command:

curl 0.0.0.0:5050/rpc -H 'content-type: application/json' -d '{
    "id": 2,
    "jsonrpc": "2.0",
    "method": "starknet_getNonce",
    "params": {
        "block_id": "pending",
        "contract_address": "0x64b48806902a367c8598f4f95c305e8c1a1acba5f082d294a43793113115691"
    }
}'

I get:

{"jsonrpc":"2.0","id":2,"error":{"code":20,"message":"Contract not found"}}

Note that:

• the same request with "block_id": "latest" works on v0.0.6
• the same request with "block_id": "pending" works on v0.0.5
• the same request with "block_id": "pending" (and an account that exists obviously) works on sepolia

The CLI output shows the account is correct and again it works with block_id is latest anyway.

Is it an intended behavior or is it a bug? starknet.js does an implicit getNonce on execute() and it does not provide any feature (except fixing the code) to change the block_id tag from pending to latest.

Not reproducible on testnet

• This issue is only present on Devnet and cannot be reproduced on the alpha-sepolia testnet (check the box if true).

To Reproduce

see the description above:

• run devnet 0.0.6
• get a contract address that exists
• run starknet_getNonce with the contract and block_id tag to pending

Devnet version

• I am using Devnet version: 0.0.6
• This happens with a dockerized Devnet (check the box if true).
• This does not appear on the following Devnet version: 0.0.5

System specifications

I did it on docker AND on my OSX with the cargo install version of starknet-devnet. Same behavior on the 2. Thank you for your help

[FabijanC]

Thank you for the clear description. @mikiw I assume it is related to your task. Can you TAL and see if your unreleased changes perhaps fix this?

[mikiw]

Yes, it's related. I'll check that.

[mikiw]

@0xknwn this problem is related to this task #445 (point defaulting to the latest state in case calls are done on pending (and there is no pending)) and once it is merged it will work as expected. Unfortunately I can't give any estimates since we are preparing to conference.

With block on demand mode cargo run -- --seed 0 --blocks-on-demand pending state is queried correctly.

[FabijanC]

Similar issue reported on Discord: https://discord.com/channels/793094838509764618/1245283649356566620