Error Handling for Long-Lived Database Transactions

[danielharrisgsr]

Describe the bug

when using the DatabaseProvider, which is a wrapper around a database transaction, the underlying transaction has a time-to-live of 5 minutes before invalidating

WARN Long-lived read transactions has been aborted open_duration=300.000069522s

This can cause bad behaviour if for example the provider is being held onto (as a struct field), and a database transaction is attempted, then the following error is encountered

InitCursor(DatabaseErrorInfo { message: \"wrong signature of a runtime object(s)\", code: -30420 }

Although not necessarily a bug, this issue is a bug/feature request for improved error handling around this case, where instead the user should see some error relating to the underlying tx timeout. Rather than a cryptic memory error related to the MDBX database

Steps to reproduce

case is in custom RPC extension

1. I implement the RethNodeCommandConfig trait, and specifically extend_rpc_modules method

let provider = components.provider().database_provider_ro()?;

gives a DatabaseProviderRO

3. Give this provider to a struct you want to implement CustomEthNamespaceServer
4. call some database-walking trait method inside your custom namespace method

let transactions_in_range = database_provider.transactions_by_block_range(block_range)

5. Call your custom endpoint via RPC after 5 minutes of your node being up

Node logs

WARN Long-lived read transactions has been aborted open_duration=300.000069522s

Platform(s)

Linux (x86)

What version/commit are you on?

0.1.0-alpha.19

What database version are you on?

1

What type of node are you running?

Full via --full flag

What prune config do you use, if any?

No response

If you've built Reth from source, provide the full command you used

No response

Code of Conduct

• I agree to follow the Code of Conduct

[emhane]

is this maybe related to #6441?