refactor!: optimizing AztecNode::getLogsByTags for new log sync algo
#19157
+113
−222
Conversation
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
This was referenced Dec 19, 2025
Contributor
Author
benesjan
force-pushed
the
12-15-refactor_more_robust_tagging_index_sync_as_recipient
branch
from
1b335df to
fc54bb0
Compare
benesjan
force-pushed
the
12-19-feat_optimizing_aztecnode_getlogsbytags_for_new_log_sync_algo
branch
from
bb40316 to
fb60766
Compare
benesjan
changed the title
AztecNode::getLogsByTags for new log sync algo
benesjan
force-pushed
the
12-15-refactor_more_robust_tagging_index_sync_as_recipient
branch
from
fc54bb0 to
32cf7bd
Compare
benesjan
force-pushed
the
12-19-feat_optimizing_aztecnode_getlogsbytags_for_new_log_sync_algo
branch
from
fb60766 to
02dee1d
Compare
benesjan
added
the
ci-no-fail-fast
benesjan
changed the title
AztecNode::getLogsByTags for new log sync algoAztecNode::getLogsByTags for new log sync algo
benesjan
changed the base branch from
12-15-refactor_more_robust_tagging_index_sync_as_recipient
to
graphite-base/19157
mverzilli
approved these changes
Dec 22, 2025
spalladino
approved these changes
Dec 22, 2025
benesjan
force-pushed
the
12-19-feat_optimizing_aztecnode_getlogsbytags_for_new_log_sync_algo
branch
from
528b8ae to
46d83bc
Compare
benesjan
force-pushed
the
graphite-base/19157
branch
from
32cf7bd to
df8f815
Compare
benesjan
added
ci-squash-and-merge
and removed
ci-no-fail-fast
Fixes https://linear.app/aztec-labs/issue/F-229/improve-log-sync-performance The return type of `getLogsByTags` did not contain block timestamp which lead to the new log sync algo being inefficient - we needed to perform a lot of calls to `getBlockHeaderByHash` endpoint to get the timestamp. In this PR I include the timestamp in the return value. This is one of 3 PRs in which I clean up the `getLogsByTags` endpoint: 1. This is the first PR - including block timestamp, 2. in the followup PR I will type the tag arg of the function to be `SiloedTag`, 3. in the last PR I will drop pagination from this endpoint. Re point 3 - pagination here doesn't really make sense because we get more logs per tag only if there are multiple devices sending logs from a given sender to a recipient.
AztecBot
force-pushed
the
12-19-feat_optimizing_aztecnode_getlogsbytags_for_new_log_sync_algo
branch
from
46d83bc to
3e97c2f
Compare
Collaborator
Flakey Tests🤖 says: This CI run detected 1 tests that failed, but were tolerated due to a .test_patterns.yml entry. |
benesjan
deleted the
12-19-feat_optimizing_aztecnode_getlogsbytags_for_new_log_sync_algo
branch
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Fixes https://linear.app/aztec-labs/issue/F-229/improve-log-sync-performance
The return type of
getLogsByTagsdid not contain block timestamp which lead to the new log sync algo being inefficient - we needed to perform a lot of calls togetBlockHeaderByHashendpoint to get the timestamp.In this PR I include the timestamp in the return value.
This is one of 3 PRs in which I clean up the
getLogsByTagsendpoint:SiloedTag,Re point 3 - pagination here doesn't really make sense because we get more logs per tag only if there are multiple devices sending logs from a given sender to a recipient.