[inf-1oop]

Problem

docker-compose.yml passes --beacon-rest-api-provider=${EXTERNAL_IP}:${RPC_PORT}, which renders as 0.0.0.0:4000. That value is wrong three ways:

No scheme	A REST endpoint is a URL. The gRPC provider on the line above is a dial target and must not have one — they look alike but are parsed by different code.
Wrong port	4000 is the gRPC port. The HTTP API is on 3500 (--grpc-gateway-port, now an alias for --http-port).
Silently inert on v5	Which is why nobody noticed.

Why it is breaking now, and not before

On Prysm v5.1.0 the REST API is enabled only by the explicit boolean, so the provider flag was dead config and the validator used gRPC:

// v5.1.0  config/features/config.go:296
if ctx.Bool(EnableBeaconRESTApi.Name) {

v7.1.8 also enables it implicitly whenever the provider flag is set:

// v7.1.8  config/features/config.go:372
if ctx.Bool(EnableBeaconRESTApi.Name) || ctx.IsSet(validatorflags.BeaconRESTApiProviderFlag.Name) {

So the value stops being ignored and starts deciding how the validator reaches the beacon.

#26 moved PRYSM_VERSION from v5.1.0 to v7.1.8 and is already merged, so this is live on main today. Any operator who pulls main and restarts their validator loses attestations.

Reproduction

Against gcr.io/prysmaticlabs/prysm/validator:v7.1.8 with the value main currently produces, repeating every 12 seconds:

WARN  flags: Enabled feature flag enable-beacon-rest-api=...
INFO  rest: Initialized REST connection provider count=1 endpoints=[[invalid endpoint]]
ERROR beacon-api: failed to get health of node error=failed to create request for
      endpoint [invalid endpoint]: parse "0.0.0.0:4000/eth/v1/node/health":
      first path segment in URL cannot contain colon  url=0.0.0.0:4000
WARN  fallback: No responsive beacon node found tried=[[invalid endpoint]]

The same run on v5.1.0 initialises no REST provider at all. Note the gRPC provider is still constructed (endpoints=[beacon:4000]) — the validator does not discard it, but the health check runs over REST, fails to build a request, and the fallback layer concludes no beacon is responsive. Net effect: zero duties.

Fix

- --beacon-rest-api-provider=${EXTERNAL_IP}:${RPC_PORT:-4000}
+ --beacon-rest-api-provider=http://beacon:${GRPC_GATEWAY_PORT:-3500}

Verified on v7.1.8 with isolated datadirs per container, so no bolt-lock contention between runs:

Config	REST endpoint	REST feature	parse errors in 40s
0.0.0.0:4000 (current main)	[invalid endpoint]	on	4
http://beacon:3500 (this PR)	http://beacon:3500	on	0
flag dropped entirely	http://127.0.0.1:3500 (default, unused)	off	0

Note on the approach

Dropping the flag was the other option: it restores v5.1.0's behaviour exactly, since the feature flag then stays off and gRPC carries the duties. Repointing it instead puts the validator on the standardised Beacon API, which is where Prysm is heading and which works against any consensus client — but it is a transport change, not only a syntax fix, and deserves a validator-in-the-loop test before the fleet moves.

What is verified here is that the endpoint parses and initialises correctly. What is not verified is that duties actually flow over REST end to end — that needs a live beacon and real keys.

Scope

docker-compose.yml only. The Caddyfile is untouched; public endpoint exposure was handled separately in #27.

🤖 Generated with Claude Code

[github-actions]

🎉 This PR is included in version 2.4.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀