Merged
Conversation
…nse (#32099) This pull request tracks the state indexing progress in eth_syncing RPC response, i.e. we will return non-null syncing status until indexing has finished.
replace `--override.prague` with `--override.osaka` Signed-off-by: jsvisa <delweng@gmail.com>
For no apparent reason, KV stores were getting wrapped in `nofreezedb` first and then in `freezerdb`.
core.BlockChainConfig.VmConfig is not a pointer, so setting the Tracer on the `vmConfig` object after it was passed to options does *not* apply it to options.VmConfig This fixes the issue by setting the value directly inside the `options` object and removing the confusing `vmConfig` variable to prevent further mistakes.
This is to avoid compatibility issues with mismatched glibc versions between the builder and deployment target. Fixes #32102
Fix the issue after initial snap sync with `gcmode=archive` enabled. ``` NewPayload: inserting block failed error="history indexing is out of order, last: null, requested: 1" ``` --------- Signed-off-by: Delweng <delweng@gmail.com> Co-authored-by: Gary Rong <garyrong0905@gmail.com>
The address filter was never checked against a maximum limit, which can be somewhat abusive for API nodes. This PR adds a limit similar to topics ## Description (AI generated) This pull request introduces a new validation to enforce a maximum limit on the number of addresses allowed in filter criteria for Ethereum logs. It includes updates to the `FilterAPI` and `EventSystem` logic, as well as corresponding test cases to ensure the new constraint is properly enforced. ### Core functionality changes: * **Validation for maximum addresses in filter criteria**: - Added a new constant, `maxAddresses`, set to 100, to define the maximum allowable addresses in a filter. - Introduced a new error, `errExceedMaxAddresses`, to handle cases where the number of addresses exceeds the limit. - Updated the `GetLogs` method in `FilterAPI` to validate the number of addresses against `maxAddresses`. - Modified the `UnmarshalJSON` method to return an error if the number of addresses in the input JSON exceeds `maxAddresses`. - Added similar validation to the `SubscribeLogs` method in `EventSystem`. ### Test updates: * **New test cases for address limit validation**: - Added a test in `TestUnmarshalJSONNewFilterArgs` to verify that exceeding the maximum number of addresses triggers the `errExceedMaxAddresses` error. - Updated `TestInvalidLogFilterCreation` to include a test case for an invalid filter with more than `maxAddresses` addresses. - Updated `TestInvalidGetLogsRequest` to test for invalid log requests with excessive addresses. These changes ensure that the system enforces a reasonable limit on the number of addresses in filter criteria, improving robustness and preventing potential performance issues. --------- Co-authored-by: zsfelfoldi <zsfelfoldi@gmail.com>
## Summary
This PR resolves Issue #31929 by reducing log noise generated by the log
indexer after `debug_setHead` operations.
## Problem Description
When `debug_setHead` is called to rewind the blockchain, blocks are
removed from the database. However, the log indexer's `ChainView`
objects may still hold references to these deleted blocks. When
`extendNonCanonical()` attempts to access these missing headers, it
results in:
1. **Repeated ERROR logs**: `Header not found number=X hash=0x...`
2. **Log noise** that can mask other important errors
3. **User confusion** about whether this indicates a real problem
## Root Cause Analysis
The issue occurs because:
- `debug_setHead` removes blocks from the blockchain database
- Log indexer's `ChainView` may still reference deleted block hashes
- `extendNonCanonical()` in `core/filtermaps/chain_view.go` tries to
fetch these missing headers
- The existing `return false` logic properly handles the error, but logs
at ERROR level
## Solution
This is a **logging improvement only** - no functional logic changes:
### Changes Made
1. **Log level**: Changed from `ERROR` to `DEBUG`
2. **Log message**: Enhanced with descriptive context about chain view
extension
3. **Comments**: Added explanation for when this situation occurs
4. **Behavior**: Maintains existing error handling (`return false` was
already present)
### Code Changes
```go
// Before
log.Error("Header not found", "number", number, "hash", hash)
return false
// After
// Header not found - this can happen after debug_setHead operations
// where blocks have been deleted. Return false to indicate the chain view
// is no longer valid rather than logging repeated errors.
log.Debug("Header not found during chain view extension", "number", number, "hash", hash)
return false
```
## Testing
### Automated Tests
- ✅ All existing filtermaps tests pass: `go test ./core/filtermaps -v`
- ✅ No regressions in related functionality
### Manual Verification
1. **Before fix**: Started geth in dev mode, generated blocks, called
`debug_setHead(3)` → **5 repeated ERROR logs**
2. **After fix**: Same scenario → **4 DEBUG logs, no ERROR noise**
### Test Environment
```bash
# Setup test environment
rm -rf ./dev-test-data
./build/bin/geth --dev --datadir ./dev-test-data --http --http.api debug,eth,net,web3 --verbosity 4
# Generate test blocks and trigger issue
curl -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"debug_setHead","params":["0x3"],"id":1}' http://localhost:8545
```
## Related Issues
- Fixes #31929
## Additional Context
This issue was reported as spurious error messages appearing after
`debug_setHead` operations. The investigation revealed that while the
error handling was functionally correct, the ERROR log level was
inappropriate for this expected scenario in development/debugging
workflows.
The fix maintains full compatibility while significantly improving the
debugging experience for developers using `debug_setHead`.
---------
Co-authored-by: Sun Tae, Kim <38067691+humblefirm@users.noreply.github.com>
Co-authored-by: zsfelfoldi <zsfelfoldi@gmail.com>
Sorry for not fully fixed in ethereum/go-ethereum#31761, now the log format of unindexing message is cleaned up, to make it consistent with the indexing message.
It should be `newPayloadV4 must only be called for prague payloads` for the V4 payload error
use `make(map, len(txpool))` to prealloc the map for the txpool content, to avoid the map growing in the loop.
…2021) Towards ethereum/go-ethereum#26974 --------- Co-authored-by: Gary Rong <garyrong0905@gmail.com>
Similar to ethereum/go-ethereum#31856, remove the not availabe shh, swarm modules in the console. --------- Co-authored-by: Gary Rong <garyrong0905@gmail.com>
This pull request refines the filtermap implementation, defining key APIs for map and epoch calculations to improve readability. This pull request doesn't change any logic, it's a pure cleanup. --------- Co-authored-by: zsfelfoldi <zsfelfoldi@gmail.com>
geth cmd: `geth --dev --dev.period 5` call: `debug.setHead` to rollback several blocks. If the `debug.setHead` call is delayed, it will trigger a panic with a small probability, due to using the null point of `fcResponse.PayloadID`. --------- Co-authored-by: Marius van der Wijden <m.vanderwijden@live.de>
1. Fix the error return format.
**todo**: ~~`bindtype` needs more complex logic to fix it.~~
`
if err != nil {
return nil, err
}
if err == nil {
return obj, nil
}
`
2. ~~Return pointer type object to avoid copying the whole struct
content.~~
3. Give the panic decision to the user.
4. Fix empty line at the end of function.
**TODO**: ~~fix some related test cases.~~
---------
Co-authored-by: Jared Wasinger <j-wasinger@hotmail.com>
Small update for logs when syncing with blsync. Downgrades the "latest filled block is not available" to warn. Co-authored-by: shantichanal <158101918+shantichanal@users.noreply.github.com>
This PR changes the trace test to block level, aiming for better execution performance. --------- Co-authored-by: zsfelfoldi <zsfelfoldi@gmail.com>
Improves the SSTORE gas calculation a bit. Previously we would pull up
the state object twice. This is okay for existing objects, since they
are cached, however non-existing objects are not cached, thus we needed
to go through all 128 diff layers as well as the disk layer twice, just
for the gas calculation
```
goos: linux
goarch: amd64
pkg: github.com/ethereum/go-ethereum/core/vm
cpu: AMD Ryzen 9 5900X 12-Core Processor
│ /tmp/old.txt │ /tmp/new.txt │
│ sec/op │ sec/op vs base │
Interpreter-24 1118.0n ± 2% 602.8n ± 1% -46.09% (p=0.000 n=10)
```
---------
Co-authored-by: Gary Rong <garyrong0905@gmail.com>
Some of the flags were deprecated, so try to hide them in the help message. And move the `--vmodule` and `--logjson` flags to the DeprecatedCategory.
Co-authored-by: Sebastian Stammler <seb@oplabs.co>
* fix!: multiply operatorFeeScalar by 100 instead of dividing by 1e6 * apply comments * apply comments * remove dup IsOperatorFeeFix --------- Co-authored-by: fakedev9999 <taehoon@succinct.xyz>
…used (ethereum-optimism#705) * core: add gauge metric for block gas used and blob gas used This can be used to track the DA footprint per block * encapsulate OPStack additions into new file and function * add histogram metrics for (blob)GasUsed * update fork.yaml * typos
This introduces more realistic limits on accelerated precompiles for the Jovian hard fork.
* core/types: Move receipt tests OP diff to separate file * core/types: Populate Jovian receipt fields
Implements a migration path for the blobpool slotter --------- Co-authored-by: lightclient <lightclient@protonmail.com> Co-authored-by: lightclient <14004106+lightclient@users.noreply.github.com> Co-authored-by: Gary Rong <garyrong0905@gmail.com>
Sets the fusaka, bpo1, bpo2 timestamps for mainnet see: https://notes.ethereum.org/@bbusa/fusaka-bpo-timeline
…lop/fusaka-mainnet params: set osaka and BPO1 & BPO2 mainnet dates (#33063)
…ptimism#718) This pull request addresses the corrupted path database with log indicating: `history head truncation out of range, tail: 122557, head: 212208, target: 212557` This is a rare edge case where the in-memory layers, including the write buffer in the disk layer, are fully persisted (e.g., written to file), but the state history freezer is not properly closed (e.g., Geth is terminated after journaling but before freezer.Close). In this situation, the recent state history writes will be truncated on the next startup, while the in-memory layers resolve correctly. As a result, the state history falls behind the disk layer (including the write buffer). In this pull request, the state history freezer is always synced before journal, ensuring the state history writes are always persisted before the others. Edit: It's confirmed that devops team has 10s container termination setting. It explains why Geth didn't finish the entire termination without state history being closed. https://github.com/ethpandaops/fusaka-devnets/pull/63/files Co-authored-by: rjl493456442 <garyrong0905@gmail.com>
kchojn
approved these changes
Nov 28, 2025
ayaz-ssvlabs
approved these changes
Dec 1, 2025
Closed
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 join this conversation on GitHub.
Already have an account?
Sign in to comment
20 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.
Description
This PR merges the upstream (original
op-geth) v1.101603.4 into a feature branch that includes the latest changes from theprotocol-v2branch (commit 75b276c).Notes
Overall, I have a high level of confidence in this merge, despite the number of merge conflicts that had to be resolved.
There are just a few areas where I wasn’t 100% sure during conflict resolution:
File:
miner/worker.go(Lines 356–359)The original
op-gethadded the following check, which slightly conflicted with our implementation.I decided to keep it:
Additional Note:
Some of our tests in the
minerandinternal/ethapipackages were not compiling, so I fixed them in commit 7a79804.