internal/ethapi: add eth_SendRawTransactionSync

[aodhgan]

New RPC method eth_sendRawTransactionSync(rawTx, timeoutMs?) that submits a signed tx and blocks until a receipt is available or a timeout elapses.

Uses a ChainEvent subscription to grep receipts and filter for the receipt of interest.

Two CLI flags to tune server-side limits:

--rpc.txsync.defaulttimeout (default wait window)

--rpc.txsync.maxtimeout (upper bound; requests are clamped)

Success/timeout unit tests added.

closes #32094

[s1na]

We can do a slight refactor with this PR merged: #32697 (comment)

[s1na]

We can do a slight refactor with this PR merged: #32697 (comment)

This PR was merged ^

[Sahil-4555]

@s1na @gawnieg
According to the EIP-7966, if a transaction is not ready to be processed, the handler should return error code 5 along with an error message. I checked the SubmitTransaction function but didn’t see this implemented—should it be added here or handling elsewhere?

[aodhgan]

@s1na @gawnieg According to the EIP-7966, if a transaction is not ready to be processed, the handler should return error code 5 along with an error message. I checked the SubmitTransaction function but didn’t see this implemented—should it be added here or handling elsewhere?

The given examples (missing nonce or insufficient funds) are already covered by their own more granular codes (https://github.com/aodhgan/go-ethereum/blob/ag/feat/add-ethsendRawTransactionSync/internal/ethapi/errors.go#L102). There is an option to coalesce these into the new error code 5 but dont see much value? (Also considering the EIP says SHOULD (vs MUST)). The "node not ready to accept new transactions" seems to require a deeper set of changes? wdyt @s1na?

[Sahil-4555]

The given examples (missing nonce or insufficient funds) are already covered by their own more granular codes (https://github.com/aodhgan/go-ethereum/blob/ag/feat/add-ethsendRawTransactionSync/internal/ethapi/errors.go#L102). There is an option to coalesce these into the new error code 5 but dont see much value? (Also considering the EIP says SHOULD (vs MUST)). The "node not ready to accept new transactions" seems to require a deeper set of changes? wdyt @s1na?

Got it, that makes sense. Since the EIP says SHOULD and not MUST, it’s optional. I just wanted to check if we plan to follow that or keep using the current detailed error codes.

[s1na]

There is an option to coalesce these into the new error code 5 but dont see much value? (Also considering the EIP says SHOULD (vs MUST)). The "node not ready to accept new transactions" seems to require a deeper set of changes? wdyt @s1na?

On the nod ready-ness we could query and see if it is in sync or not, but that's not something we do for the other sendTransaction variants. I'm not sure why it was introduced to this method.

On the other point I think I agree that coalescing means losing info, and given the wording, I'd go with the current approach.

[s1na]

LGTM thanks for the contribution!

[melgaralberto21]

Thanks