Possible inconsistency with base-reth-node pruning flags when using custom args

[mslord213]

Summary

It looks like base-reth-node may not always apply pruning flags from RETH_PRUNING_ARGS when custom arguments are passed to the container entrypoint.

I might be misunderstanding the intended behaviour, but from a user perspective it is not obvious whether pruning flags are guaranteed to be applied when additional args are provided.

Steps to Reproduce

1. Run base-reth-node with an explicit pruning env var and at least one additional arg, e.g.:

   docker run \
     -e RETH_PRUNING_ARGS="--prune.trie.before=100000" \
     ghcr.io/base/node-reth:latest \
     --http

heck the node logs / effective flags to confirm which arguments are actually used at runtime.

Expected Behavior

The node runs with both:

flags coming from RETH_PRUNING_ARGS

and any extra args passed to the container (e.g. --http),

and the behaviour is clearly documented.

Actual Behavior

From a quick test it is not entirely clear whether pruning flags from RETH_PRUNING_ARGS are consistently applied when extra args are passed. It would be great to clarify the intended behaviour and, if needed, adjust the entrypoint logic or documentation.

Relevant code

The behaviour seems to be controlled by the reth entrypoint script, where RETH_PRUNING_ARGS and "$@" are combined.

Proposed Improvement

Either:

ensure that RETH_PRUNING_ARGS are always appended in a predictable way when extra args are passed, or

document clearly how pruning flags interact with additional args so users know what to expect.

Why this matters

Users rely on pruning configuration to control disk usage and node performance.

When combining env-based flags and explicit args, it is important that the final runtime behaviour is predictable and well documented.

Environment

Image: base-reth-node (latest at the time of writing)

Platform: Docker / Linux