Etherpull#2
Etherpull#2SherfeyInv wants to merge 2172 commits intoSherfeyInv:dependabot/go_modules/google.golang.org/protobuf-1.33.0from
Conversation
SherfeyInv
changed the base branch from
master
to
dependabot/go_modules/google.golang.org/protobuf-1.33.0
|
@dependabot rebase |
|
|
24 similar comments
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
…34878) The refactor from `for el := plist.Front(); ...; el = el.Next()` to the new `iterList` iterator in #34743 silently dropped two things needed by resetTimeout: 1. `nextTimeout = el.Value.(*replyMatcher)` at the top of the loop. This assignment is what gives `nextTimeout` its documented meaning ("head of plist when timeout was last reset"), and what makes the early-return optimization at the top of resetTimeout work. Without it, nextTimeout is only ever written to nil, so `nextTimeout == plist.Front().Value` is always false and the optimization is dead. 2. `nextTimeout.errc <- errClockWarp` in the clock-warp branch now reads a stale or nil pointer. Prior to the refactor, the inner assignment kept nextTimeout pointing at the current matcher so its errc was the right channel to receive the errClockWarp signal. After the refactor, on first entry into the clock-warp branch nextTimeout is nil, which panics the UDPv4 loop goroutine with a nil pointer deref and takes discv4 down. Re-assign `nextTimeout = p` at the head of the loop (restoring the documented invariant) and send the clock-warp error on `p.errc` rather than the now-stale `nextTimeout.errc`. The clock-warp branch triggers only when the system clock jumps backward after a deadline is assigned (deadline - time.Now() >= 2*respTimeout, i.e. at least ~500ms backward jump), which is why this regression slipped past CI - it is not exercised by any existing unit test, and writing one would require plumbing a clock through the loop.
## Summary Fixes #31917. `geth era-download` now only prints `is stale` when an existing downloaded file fails checksum verification. Missing files are still downloaded normally, but no longer get mislabeled as stale. ## Why `DownloadFile` used `verifyHash` for both missing files and checksum mismatches, then printed `is stale` for any error. This made first-time downloads look like corrupt or outdated files. ## Validation - `make all` - `go run ./build/ci.go test` - `go run ./build/ci.go lint` - `go run ./build/ci.go check_generate` - `go run ./build/ci.go check_baddeps` --------- Co-authored-by: Felix Lange <fjl@twurst.com>
Implements https://github.com/ethereum/execution-apis/pull/786/changes as discussed on standup today --------- Co-authored-by: Gary Rong <garyrong0905@gmail.com>
When `io.Copy` succeeds but the buffered `Close` fails (e.g. disk full on `Flush`), the error was swallowed and verification reported a misleading hash mismatch instead of the real I/O failure. Keep the `Close` error when `io.Copy` didn't already produce one. --------- Co-authored-by: Jared Wasinger <j-wasinger@hotmail.com>
This PR adds `AdoptSyncedState()` alongside `Enable()`. It does the same pathdb bookkeeping (now factored into a shared `resetForReactivation()` helper), but skips the regeneration. The wiring/calling code lands in #34626 --------- Co-authored-by: Gary Rong <garyrong0905@gmail.com>
This is an alternative PR for #34746. This PR implements the second approach among the two possible solutions mentioned in the above PR. Requests for unavailable items are possible when the peer is following a different fork from us. However this is not expected to happen frequently. Considering the amount of complexity added to the codebase, the simpler approach (this PR) can be preferred.
#32924) This PR makes a small update to the `Pending()` method in the legacy pool. By changing the lock from exclusive to read-only, it aims to improve concurrency performance. --------- Co-authored-by: rjl493456442 <garyrong0905@gmail.com>
Fixes the exclusion list of the accessListTracer. --------- Co-authored-by: Sina M <1591639+s1na@users.noreply.github.com>
…4888) This fixes an issue where packets send to the `Unhandled` channel configured on discv4 could be corrupted when the packet buffer gets reused. --------- Co-authored-by: Felix Lange <fjl@twurst.com>
replace the not used event.Typemux to event.Feed --------- Co-authored-by: Felix Lange <fjl@twurst.com>
) Fixes #34881 This fixes a hang in `Table.waitForNodes`. It is a replacement for PRs #34890, #33665 which tried to fix the same issue in a different way. - #34890 doesn't really fix the issue, just makes it less likely - #33665 tries to fix it by moving the feed send outside of the lock I created this PR because I want to keep the synchronous node feed sending in `Table.nodeAdded`. --------- Co-authored-by: Csaba Kiraly <csaba.kiraly@gmail.com>
) `GetBlobs` returned early when `CellProofsAt` reported corrupted/out-of-bounds proofs, dropping every blob already collected and aborting the remaining hashes — a single bad sidecar killed the whole Engine API batch for consensus clients. Replaced the `return nil, nil, nil, err` with `log.Error + continue` so the slot stays `nil` per the sparse-array contract, matching the store/RLP/nil-sidecar branches a few lines above.
Passing `--graphql=false` currently still registers the GraphQL handler because the startup path checks whether the flag was set, not its boolean value. This switches the registration condition to use `ctx.Bool`, so explicit false disables GraphQL while the default behavior remains unchanged.
I was tracing a signature verification issue in a nocgo build and found that `VerifySignature` doesn't validate hash length. #33104 added the check to `Sign` and `sigToPub` but missed this one. The cgo path in `secp256k1/secp256.go` already rejects non-32-byte hashes, so the nocgo path should do the same — otherwise a wrong-length hash gets passed to decred's `Verify` and silently gives a bogus result.
This fixes a theoretical overflow condition if an account has an impossibly high nonce.
Removes the appveyor.yml since we moved to github runners. --------- Co-authored-by: Sina Mahmoodi <itz.s1na@gmail.com> Co-authored-by: Felix Lange <fjl@twurst.com>
Passing `--dev=false` currently still enters the dev-mode startup path because a couple of branches check whether the flag was set, not its boolean value. This switches those branches to use `ctx.Bool`, so explicit false does not start dev mode or emit a dev genesis, while `--dev` keeps its existing behavior.
Changes core.Message to use Uint256 which is faster --------- Co-authored-by: Gary Rong <garyrong0905@gmail.com>
20 participants
No description provided.