Summary
I’m proposing a small routing reliability improvement for HyperBEAM:
add configurable raw gateway priority for hydration-related /raw requests
instead of relying on a single default raw gateway.
I’ve prepared the change on my fork here:
Why this seems needed
While debugging local HyperBEAM process hydration, I ran into a failure mode
where:
- process hydration / scheduler-location resolution needed a tx via
/raw/ <txid>
arweave.net returned 404- another gateway returned
200 for the same tx
- HyperBEAM still failed with
no_viable_gateway
From an operator perspective, this means hydration can fail even when the tx
exists and is retrievable, simply because the default raw route is too rigid.
Problem
Today, default raw fetch behavior is effectively pinned to a single gateway
for:
That creates a single-gateway dependency for hydration-sensitive paths.
When a tx is:
- delayed
- unavailable
- incompletely propagated
- or temporarily missing
on that gateway, process reads and hydration can fail even though another
gateway can serve the same object.
Proposed fix
Introduce operator-configurable raw gateway priority:
- add
gateway_priorities
- generate
/raw and /arweave/raw routes from that list
- preserve current behavior by default when no custom list is provided
- regenerate default routes after config load so normal node config actually
affects runtime routing
- accept both native list input and flat-config string input for usability
Why this helps
This makes HyperBEAM more production-friendly by:
- reducing sensitivity to single-gateway availability gaps
- allowing operators to configure fallback order without a full custom route
table
- preserving stable defaults for nodes that don’t need custom behavior
Scope
I intentionally kept the branch narrow:
- no project-specific gateway defaults
- no app-specific local-node changes
- no unrelated parser changes
Validation
From the branch:
Branch / code
If useful, I’m happy to turn this into a PR or revise it to match the team’s
preferred configuration approach.
Summary
I’m proposing a small routing reliability improvement for HyperBEAM:
add configurable raw gateway priority for hydration-related
/rawrequestsinstead of relying on a single default raw gateway.
I’ve prepared the change on my fork here:
https://github.com/Jharmony/HyperBEAM/tree/impr/gateway-priority-routing
Why this seems needed
While debugging local HyperBEAM process hydration, I ran into a failure mode
where:
/raw/ <txid>arweave.netreturned404200for the same txno_viable_gatewayFrom an operator perspective, this means hydration can fail even when the tx
exists and is retrievable, simply because the default raw route is too rigid.
Problem
Today, default raw fetch behavior is effectively pinned to a single gateway
for:
/raw/arweave/rawThat creates a single-gateway dependency for hydration-sensitive paths.
When a tx is:
on that gateway, process reads and hydration can fail even though another
gateway can serve the same object.
Proposed fix
Introduce operator-configurable raw gateway priority:
gateway_priorities/rawand/arweave/rawroutes from that listaffects runtime routing
Why this helps
This makes HyperBEAM more production-friendly by:
table
Scope
I intentionally kept the branch narrow:
Validation
From the branch:
rebar3 compileBranch / code
https://github.com/Jharmony/HyperBEAM/tree/impr/gateway-priority-routing
If useful, I’m happy to turn this into a PR or revise it to match the team’s
preferred configuration approach.