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)
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.EthGetMessageCidByTransactionHashFilecoin.EthGetTransactionByHashand in some circumstances, could return a non-null result even though the
HashtoCidentry has been correctly deleted.Task summary
calibnet_eth_mapping_checkCI scriptnullwhen an entry has been deleted (This could be done by transforming back theCidto anHashand seeing if there's a match)Acceptance Criteria