erigontech / erigontech/erigon

db/downloader, node/interfaces: report snapshot-download progress over the downloader RPC

Open
#23,414 0 comments 0 reactions 0 assignees View on GitHub
ErigonDB
Dominant language
Go
Stars
3.6k
Forks
1.5k
Avg merge
1d 16h
Merged PRs (30d)
455

Description

`eth_syncing` reports snapshot-download progress only when the downloader runs in-process. With `--downloader.api.addr` the progress reporter is a deliberate no-op, so the whole OtterSync window shows no progress in that setup.

## Why

The progress capability is a Go-level interface, `dbservices.DownloadProgressReport`:

```go
Completed() (done, total uint64) // total == 0 means unknown
ResetProgress()
```

It is implemented only by `*db/downloader.Downloader`. `RpcClient` and `directGrpcServerClient` unwrap to it when the wrapped client is the in-process downloader; the generated gRPC client that `node/components/downloader/provider.go` returns for an external address cannot, because `service Downloader` in `node/interfaces/downloader/downloader.proto` has no progress RPC — only `Seed`, `Download`, `Delete`. `startSnapshotDownloadProgressReporter` then returns its no-op and the reply keeps the stage shape.

## Proposal

- Add the progress calls to `service Downloader` in `node/interfaces/downloader/downloader.proto`: one RPC returning done/total bytes plus a reset, or a single request carrying a reset flag — shape to be settled in review. The proto lives in-repo, so `make gen` covers the codegen.
- Implement them on `GrpcServer` (`db/downloader/downloader_grpc_server.go`) over the existing `Completed()` / `ResetProgress()`.
- Make `RpcClient` implement `DownloadProgressProvider` by forwarding over the RPC, instead of unwrapping only to the in-process downloader.
- Drop the no-op branch in `startSnapshotDownloadProgressReporter` once every supported transport can report.

## Acceptance

With an external downloader, `eth_syncing` shows the byte-completion ratio mapped onto blocks during OtterSync, the same as the in-process case.

Follow-up to #22716 (round-4 item 6).

Contributor guide

Open the contributing guide

Research direction

Start with node/interfaces/downloader/downloader.proto and the existing Seed, Download, and Delete RPCs; then inspect db/downloader/downloader_grpc_server.go and node/components/downloader/provider.go. Run make gen after the RPC shape is settled, and trace startSnapshotDownloadProgressReporter. Done means an external downloader lets eth_syncing show the byte-completion ratio mapped onto blocks during OtterSync.

Written by the indexing model from the issue text.

Assessment

Tech stack
go, grpc
Domain
api, backend, distributed-systems
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
55/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.