Distinguishing a stale Stellar contract entry from a stale reader
A cache displays the same contract value for hours. The ledger on which that entry last changed and the ledger up to which the RPC has read answer two different questions.
Read the entry together with the observation height
Supply the contract data key as a base64-encoded XDR LedgerKey in LEDGER_KEY_XDR. A contract address alone does not identify its storage key. Set STELLAR_RPC to your endpoint. The query below keeps the identifiers and heights from the response without dumping the entry payload.
jq -n --arg k "$LEDGER_KEY_XDR" '{jsonrpc:"2.0",id:4,method:"getLedgerEntries",params:{keys:[$k]}}' |
curl -sS -H 'Content-Type: application/json' --data-binary @- "$STELLAR_RPC" |
jq 'if .error then .error else .result | {latestLedger,entries:[.entries[]? | {key,lastModifiedLedgerSeq}]} end'
Interpret two samples from the same network
Suppose latestLedger moves from 880 to 890 while lastModifiedLedgerSeq stays at 852 for the same key. The reader has advanced and the observed entry still reports its last modification at 852. Rebuilding that cache item on every new ledger would do needless work. If the key is absent in the next response, handle that separately. Keeping the previously cached value as though the latest lookup had returned it would hide the change in availability.