Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Problem:
When using
subscribe
at admin RPC port to send webhooks for the transaction stream to a backend, on large(r) ledgers the endpoint was consistently receiving fewer HTTP POSTs with TX information than the amount of transactions in a ledger.This resulted in some XamanWallet users, on larger ledgers, not always receiving their transaction push notifications.
Details
Admin command RPC Post to URL had a 32 queue length (hardcoded) resulting in dropping TX notifications.
As this is an admin-command only, I stripped out the entire queue length check. If admin, you should know what you are doing. If your endpoint can't efficiently handle the TPS, your problem.
Also: shorter TTL for outgoing RPC HTTP calls: was 10 minutes PER REQUEST, now is 30 seconds (still too long, but 10 minutes is a guaranteed shit show if the calls keep on hanging and stack up, especially since the 32 queue length for HTTP calls is now removed).
While dropping the queue length limit on sent WebHooks could be considered dangerous, it's guarded by admin-RPC port anyway:
rippled/src/xrpld/rpc/handlers/Subscribe.cpp
Line 51 in 63209c2
Finally: