Skip to content

rpc: handle ss txs in GetLogsByHash#124

Merged
marcello33 merged 1 commit into
release/3.2-developfrom
mardizzone/POS-3269
Feb 25, 2026
Merged

rpc: handle ss txs in GetLogsByHash#124
marcello33 merged 1 commit into
release/3.2-developfrom
mardizzone/POS-3269

Conversation

@marcello33

@marcello33 marcello33 commented Feb 18, 2026

Copy link
Copy Markdown

Handle ss txs in GetLogsByHash.

@marcello33 marcello33 requested a review from a team February 18, 2026 15:34
manav2401
manav2401 approved these changes Feb 18, 2026
View reviewed changes

@manav2401 manav2401 left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall LGTM, just a small nit. Do you think it makes sense to not return an error back to the user if there's any error fetching bor events / receipts? It might still be worth returning logs of regular transactions back in case there's any error fetching bor receipts.

The current way also works as it's more aggressive in returning errors and users can quickly report back to us making it easy for us to fix.

@marcello33

marcello33 commented Feb 18, 2026 •
edited
Loading

Copy link
Copy Markdown
Author

Overall LGTM, just a small nit. Do you think it makes sense to not return an error back to the user if there's any error fetching bor events / receipts? It might still be worth returning logs of regular transactions back in case there's any error fetching bor receipts.

The current way also works as it's more aggressive in returning errors and users can quickly report back to us making it easy for us to fix.

Overall LGTM, just a small nit. Do you think it makes sense to not return an error back to the user if there's any error fetching bor events / receipts? It might still be worth returning logs of regular transactions back in case there's any error fetching bor receipts.

The current way also works as it's more aggressive in returning errors and users can quickly report back to us making it easy for us to fix.

That's actually a good point and I questioned myself about it when implementing.
I decided to go this way because in principle we want to make sure bor receipts are there, especially post Madhugiri HF, and react fast in case of fixes needed on errors reported by users.
Also, I think this is the default behaviour also in other methods.

WDYT?

@marcello33 marcello33 merged commit b84fd52 into release/3.2-develop Feb 25, 2026
6 of 9 checks passed
pratikspatil024 added a commit that referenced this pull request Mar 26, 2026
@pratikspatil024 @marcello33
@lucca30 @manav2401
v3.5.0 (#141)
230b11a 
* rpc: handle ss txs in GetLogsByHash (#124)

* core, execution, polygon, rpc: giugliano HF - decode gas params from extra data and serve via RPC (#132)

* core, execution, polygon, rpc: giugliano HF - decode gas params from extra data and serve via RPC

* added optional borExtra param to eth_getBlockByNumber/Hash to get gas params and tx dependency

* fix tests, not related

* renamed the rpc field to decodedExtra

* Giugliano HF (#135)

* giugliano HF

* upgrade lint to fix CI

* bumps lint on ci

* params: version bump to v3.5.0-beta

* added giugliano block for amoy (#137)

* params: version bump to v3.5.0-beta2

* core/vm: enable kzg back for madhugiri forks (#139)

* added giugliano block for mainnet (#140)

* params: version bump to v3.5.0

---------

Co-authored-by: Marcello Ardizzone <marcelloardizzone@hotmail.it>
Co-authored-by: Lucca Martins <lucca_martins30@yahoo.com.br>
Co-authored-by: Manav Darji <manavdarji.india@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@manav2401 manav2401 manav2401 approved these changes

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@marcello33 @manav2401