Summary
While auditing the onboarding flow in a clean environment (GitHub Codespaces), I identified a gap in the documentation regarding how runtime configurations affect transaction fee-priority. The current _troubleshooting-users-partial.mdx and .env.example do not provide explicit guidance on required RPC/provider fee configurations, leading to inconsistent behavior in default setups.
Environment
Repo: OffchainLabs/arbitrum-docs
Reproduction Path:
Fresh GitHub Codespaces environment.
Default .env.example (no additional RPC/provider overrides).
Standard master branch build.
Diagnostic Observations
In a fresh/default setup, transactions may behave unexpectedly regarding fee-priority handling. This occurs because the environment lacks specific runtime configuration guidance that the provider requires to manage L2 fee headers correctly.
Observed behavior:
Default Setup: When following the standard guide with a default .env, the system lacks explicit parameters for fee-priority overrides.
Result: Fee-priority settings may be silently ignored or default to sub-optimal L1/L2 parity settings, creating a discrepancy between the expected behavior described in the docs and the actual runtime outcome.
Technical Analysis
Configuration Gap: The .env.example provides a baseline but does not highlight the mandatory RPC settings required for advanced fee handling (EIP-1559/Priority).
Documentation Oversight: docs/partials/_troubleshooting-users-partial.mdx focuses on general connectivity but omits a "Runtime/Environment Parity" check, which is crucial for developers troubleshooting stuck or low-priority transactions.
Onboarding Experience: This missing guidance causes friction for developers who assume the default environment is fully optimized for fee-priority testing.
Request for Validation
I would like to confirm with the maintainers:
Is it intended for the troubleshooting guide to remain focused on UI/connectivity, or should we include Runtime/Environment Parity checks?
Should the .env.example be expanded to include placeholders for required RPC/provider fee configurations to ensure consistent behavior across different environments?
Summary
While auditing the onboarding flow in a clean environment (GitHub Codespaces), I identified a gap in the documentation regarding how runtime configurations affect transaction fee-priority. The current _troubleshooting-users-partial.mdx and .env.example do not provide explicit guidance on required RPC/provider fee configurations, leading to inconsistent behavior in default setups.
Environment
Repo: OffchainLabs/arbitrum-docs
Reproduction Path:
Fresh GitHub Codespaces environment.
Default .env.example (no additional RPC/provider overrides).
Standard master branch build.
Diagnostic Observations
In a fresh/default setup, transactions may behave unexpectedly regarding fee-priority handling. This occurs because the environment lacks specific runtime configuration guidance that the provider requires to manage L2 fee headers correctly.
Observed behavior:
Default Setup: When following the standard guide with a default .env, the system lacks explicit parameters for fee-priority overrides.
Result: Fee-priority settings may be silently ignored or default to sub-optimal L1/L2 parity settings, creating a discrepancy between the expected behavior described in the docs and the actual runtime outcome.
Technical Analysis
Configuration Gap: The .env.example provides a baseline but does not highlight the mandatory RPC settings required for advanced fee handling (EIP-1559/Priority).
Documentation Oversight: docs/partials/_troubleshooting-users-partial.mdx focuses on general connectivity but omits a "Runtime/Environment Parity" check, which is crucial for developers troubleshooting stuck or low-priority transactions.
Onboarding Experience: This missing guidance causes friction for developers who assume the default environment is fully optimized for fee-priority testing.
Request for Validation
I would like to confirm with the maintainers:
Is it intended for the troubleshooting guide to remain focused on UI/connectivity, or should we include Runtime/Environment Parity checks?
Should the .env.example be expanded to include placeholders for required RPC/provider fee configurations to ensure consistent behavior across different environments?