This repository was archived by the owner on Jun 9, 2026. It is now read-only.
feat: immediate receipt issuance#169
Merged
Merged
Conversation
ARR4N
force-pushed
the
arr4n/receiptcache
branch
from
e1e6189 to
23dc7ee
Compare
ARR4N
force-pushed
the
arr4n/receiptcache
branch
from
23dc7ee to
133d00f
Compare
Collaborator
Author
|
Sorry for the crap code the last few days. I'm well now and thinking more clearly so have completely refactored this. |
Co-authored-by: Stephen Buttolph <stephen@avalabs.org> Signed-off-by: Arran Schlosberg <519948+ARR4N@users.noreply.github.com>
Co-authored-by: Stephen Buttolph <stephen@avalabs.org> Signed-off-by: Arran Schlosberg <519948+ARR4N@users.noreply.github.com>
StephenButtolph
approved these changes
Feb 24, 2026
powerslider
pushed a commit
that referenced
this pull request
Feb 25, 2026
The `geth` APIs fetch individual transaction results by loading the entire block's receipts, which forces all senders to wait until the whole block has finished execution. This PR introduces a cache of recent receipts, and intercepts the `GetTransactionReceipt()` RPC method, serving from the cache if it holds the data. This allows for receipt issuance immediately after _transaction_ execution, not after _block_ execution. The cache is cleared at the same time as the respective block is ejected from `VM` memory. To further reduce polling of `GetTransactionReceipt()`, the caching mechanism is aware of pending (accepted but not executed) transactions and will block until they are executed or context cancellation occurs. The test case in which a pending transaction returns `nil, nil` for receipt requests is therefore removed. The `saexec.syncMap` type is a thread-safe key-value store that aims to reduce lock contention by spreading reads and writes over independent buckets. Without this, every enqueued block (execution thread) and every cache clearance (GC) would block receipt storage / retrieval. Both scenarios only hold 1/256 locks at any time to avoid starving the RPCs. Although existing receipt tests hit the current path, an explicit unit test demonstrates that blocking of a transaction doesn't block earlier receipt availability. Closes #208 --------- Signed-off-by: Arran Schlosberg <519948+ARR4N@users.noreply.github.com> Co-authored-by: Stephen Buttolph <stephen@avalabs.org>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
3 participants
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.
The
gethAPIs fetch individual transaction results by loading the entire block's receipts, which forces all senders to wait until the whole block has finished execution. This PR introduces a cache of recent receipts, and intercepts theGetTransactionReceipt()RPC method, serving from the cache if it holds the data. This allows for receipt issuance immediately after transaction execution, not after block execution. The cache is cleared at the same time as the respective block is ejected fromVMmemory.To further reduce polling of
GetTransactionReceipt(), the caching mechanism is aware of pending (accepted but not executed) transactions and will block until they are executed or context cancellation occurs. The test case in which a pending transaction returnsnil, nilfor receipt requests is therefore removed.The
saexec.syncMaptype is a thread-safe key-value store that aims to reduce lock contention by spreading reads and writes over independent buckets. Without this, every enqueued block (execution thread) and every cache clearance (GC) would block receipt storage / retrieval. Both scenarios only hold 1/256 locks at any time to avoid starving the RPCs.Although existing receipt tests hit the current path, an explicit unit test demonstrates that blocking of a transaction doesn't block earlier receipt availability.
Closes ava-labs/avalanchego#5252