consensus-entrypoint always overrides BASE_NODE_P2P_ADVERTISE_IP and exits if public IP discovery fails

[Gercekkriptocu]

Summary

consensus-entrypoint always calls get_public_ip and assigns its result to BASE_NODE_P2P_ADVERTISE_IP, overriding any value the operator set in their env file. If none of the four upstream IP services are reachable, the script exits with code 8 and the node fails to start.

What I found

In consensus-entrypoint:

• The script unconditionally invokes get_public_ip against four external endpoints (ifconfig.me, api.ipify.org, ipecho.net, v4.ident.me).
• It then runs export BASE_NODE_P2P_ADVERTISE_IP=$PUBLIC_IP, which silently replaces any value already provided via .env.
• If all four endpoints are unreachable (firewalled host, restricted egress, transient network failure), the script exits with code 8 and the consensus container will not start.

Expected behavior

• If the operator has already set BASE_NODE_P2P_ADVERTISE_IP, the script should respect that value and skip discovery.
• Discovery failure should not be a hard startup failure when the operator has provided their own value.

Suggested fix

Skip discovery when BASE_NODE_P2P_ADVERTISE_IP is already set:

if [[ -z "${BASE_NODE_P2P_ADVERTISE_IP:-}" ]]; then ... fi

Impact

• Operators on hosts with restricted outbound HTTP cannot start the consensus node even when they know their public IP.
• Operators behind NAT or with a static advertised IP cannot pin it through env config.

[schoolkamsergj]

Thanks for the clear write-up — I can reproduce/confirm the root cause.

Root cause

consensus-entrypoint currently runs public IP discovery unconditionally (curling the 4 upstream services) and then does export BASE_NODE_P2P_ADVERTISE_IP=$PUBLIC_IP, which will overwrite any value the operator already set via .env/container env.

When all 4 endpoints are unreachable (restricted egress, temporary outage, firewalled host), get_public_ip exits non-zero (code 8) and the container hard-fails even though an operator may already know the correct advertise IP.

Proposed shell fix

The suggested guard looks correct:

if [[ -z "${BASE_NODE_P2P_ADVERTISE_IP:-}" ]]; then
  # discovery
fi

This prevents overwriting a user-provided value and skips discovery entirely when the var is set.

Edge case: var set to empty string

With :-, both unset and set-but-empty evaluate to the empty string, so -z will treat them the same and still run discovery.

That's probably fine if an empty string is considered "not configured", but if you want to treat an explicitly empty value as intentional (i.e. "don't discover, but also don't advertise"), you'd need a different check (e.g. [[ -v BASE_NODE_P2P_ADVERTISE_IP ]] in bash, or [[ ${BASE_NODE_P2P_ADVERTISE_IP+x} ]]-style tests).

Suggestion on the exit(8) behavior

Even if you keep exit code 8 for "discovery failed", it seems safer to only hard-exit when we actually need discovery:

• If BASE_NODE_P2P_ADVERTISE_IP is already non-empty, don't call discovery at all (preferred).
• If discovery is still called for some reason and returns 8, consider not exiting hard when a valid advertise IP is already present.

Overall: +1 to merging this fix — it makes startup more robust for operators with restricted outbound HTTP while preserving current behavior when the variable is not provided.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[schoolkamsergj]

Bumping this — still relevant. With Base Beryl (v1.1.1) released yesterday, it would be worth confirming whether consensus-entrypoint now respects a pre-set BASE_NODE_P2P_ADVERTISE_IP or still unconditionally overwrites it. The one-line fix (if [[ -z "${BASE_NODE_P2P_ADVERTISE_IP:-}" ]]) would help operators on restricted-egress hosts and those with static advertised IPs.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[github-actions]

This issue was closed because it has been inactive for 5 days since being marked as stale.