You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Ethereum mapping TTL feature allows entries to be deleted after a setup duration (e.g., twenty-four hours).
After this period, RPC methods involving mapping like:
Filecoin.EthGetMessageCidByTransactionHash
Filecoin.EthGetTransactionByHash
and in some circumstances, could return a non-null result even though the Hash to Cid entry has been correctly deleted.
Task summary
Find some of those hashes using calibnet_eth_mapping_check CI script
Investigate how Lotus behaves for those hashes
We should either properly document this behavior because it can be a source of surprise for API consumers
OR we should find a way to handle those corner cases and always return null when an entry has been deleted
(This could be done by transforming back the Cid to an Hash and seeing if there's a match)
Acceptance Criteria
Add unit test covering this corner case
The text was updated successfully, but these errors were encountered:
Issue summary
The Ethereum mapping TTL feature allows entries to be deleted after a setup duration (e.g., twenty-four hours).
After this period, RPC methods involving mapping like:
Filecoin.EthGetMessageCidByTransactionHash
Filecoin.EthGetTransactionByHash
and in some circumstances, could return a non-null result even though the
Hash
toCid
entry has been correctly deleted.Task summary
calibnet_eth_mapping_check
CI scriptnull
when an entry has been deleted(This could be done by transforming back the
Cid
to anHash
and seeing if there's a match)Acceptance Criteria
The text was updated successfully, but these errors were encountered: