For eth_sendRawTransaction, if the calldata exceeds 5120 bytes, HFS is used to temporarily store the bytecode on the network. The intention is to delete the file created to hold the calldata regardless of whether the transaction succeeds or fails. However, the current implementation only deletes the file if no error is thrown; if an error occurs, the file deletion is skipped.
Solution
Here are a couple of potential solutions:
Attach the fileId to the error being thrown, allowing access to it directly from the error object.
Use a cache to temporarily store the fileId, allowing it to be re-accessed as needed, with the record removed from the cache after deletion.
Problem
For
eth_sendRawTransaction, if the calldata exceeds 5120 bytes, HFS is used to temporarily store the bytecode on the network. The intention is to delete the file created to hold the calldata regardless of whether the transaction succeeds or fails. However, the current implementation only deletes the file if no error is thrown; if an error occurs, the file deletion is skipped.Solution
Here are a couple of potential solutions:
fileIdto the error being thrown, allowing access to it directly from the error object.fileId, allowing it to be re-accessed as needed, with the record removed from the cache after deletion.Alternatives
No response