Add instruction of how to debug the fuel-core
#1236
Assignees
Labels
Comments
xgreenx
added
good first issue
bvrooman
pushed a commit
that referenced
this issue
Aug 3, 2023
Related issues: - #1236 This PR disables P2P by default, and adds a new flag to the `fuel-core` CLI to allow users to expressly enable P2P: ``` --enable-p2p ``` Currently, the P2P service is only enabled when the user provides CLI arguments for `keypair` and `network`. If either of these values are missing, P2P is implicitly disabled without warning to the user. There is no way to tell if the user accidentally omitted these values, or deliberately omitted them in order to disable P2P. A better user experience is to enable P2P explicitly using `--enable-p2p` and to make `keypair` and `network` mandatory. This will raise an error if either of these values is missing. P2P should be disabled by default. This flag replaces having to add or remove the `network` argument to enable or disable P2P implicitly. If a user wants to run `fuel-core` with P2P, and supplies `--enable-p2p`, but forgets to include `keypair` and/or `network`, they will encounter an error: ``` error: the following required arguments were not provided: --keypair <KEYPAIR> --network <NETWORK> ``` --------- Co-authored-by: Green Baneling <XgreenX9999@gmail.com>
This was referenced Aug 7, 2023
bvrooman
pushed a commit
that referenced
this issue
Aug 15, 2023
Related issues: - #1236 This PR adds a new CLI flag to enable the Relayer service `--enable-relayer`, and disable the Relayer service by default. When supplying the `--enable-relayer` flag, the `--relayer` argument becomes mandatory, and omitting it is an error. Similarly, providing a `--relayer` argument without the `--enable-relayer` flag is an error. Lastly, providing the `--keypair` or `--network` arguments will also produce an error if the `--enable-p2p` flag is not set.
This was referenced Aug 16, 2023
bvrooman
pushed a commit
that referenced
this issue
Aug 22, 2023
Related issues: - #1236 This PR adds conditional support for loading a local `.env` for environment variables. This support is only enabled when compiling the client binary with the `env` feature or when passing `--all-features` to Cargo. This is not enabled by default for production environments. Users can add a `.env` to the root directory of their local copy of their Fuel node (or wherever their working directory is). This helps users provide CLI arguments in a way that is more convenient and more secure than entering these values in an IDE directly: - Users can reuse environment variables across IDEs (e.g., VS Code and CLion) and IDE configurations seamlessly, rather than specifying them in each IDE specific configuration - Users can avoid putting secrets in shared commands or configurations - CLion users can greatly shorten their `run` commands, which is helpful since the configuration window does not word wrap long commands The `.env` is also added to `.gitignore` to prevent users from uploading individual environment configurations that may include secrets. This approach acts as a sort of stop gap for handling secrets before we have SOPS. This PR also renames the internal `eth_client` component of the relayer configuration to `relayer`. This allow users to use the environment variable name `RELAYER` to supply this value. Prior to this, the CLI expected an environment variable called `ETH_CLIENT`, even though the CLI argument is named `relayer`. Note: Due to the order in which the initialization functions are called, we cannot supply `RUST_LOG` in the .env file; this has to be provided elsewhere or directly to Cargo.
bvrooman
pushed a commit
that referenced
this issue
Aug 22, 2023
Related issues: - Closes #1236 This PR adds documentation on debugging. --------- Co-authored-by: Brandon Kite <brandonkite92@gmail.com> Co-authored-by: Green Baneling <XgreenX9999@gmail.com>
crypto523
added a commit
to crypto523/fuel-core
that referenced
this issue
Oct 7, 2024
Related issues: - FuelLabs/fuel-core#1236 This PR disables P2P by default, and adds a new flag to the `fuel-core` CLI to allow users to expressly enable P2P: ``` --enable-p2p ``` Currently, the P2P service is only enabled when the user provides CLI arguments for `keypair` and `network`. If either of these values are missing, P2P is implicitly disabled without warning to the user. There is no way to tell if the user accidentally omitted these values, or deliberately omitted them in order to disable P2P. A better user experience is to enable P2P explicitly using `--enable-p2p` and to make `keypair` and `network` mandatory. This will raise an error if either of these values is missing. P2P should be disabled by default. This flag replaces having to add or remove the `network` argument to enable or disable P2P implicitly. If a user wants to run `fuel-core` with P2P, and supplies `--enable-p2p`, but forgets to include `keypair` and/or `network`, they will encounter an error: ``` error: the following required arguments were not provided: --keypair <KEYPAIR> --network <NETWORK> ``` --------- Co-authored-by: Green Baneling <XgreenX9999@gmail.com>
crypto523
added a commit
to crypto523/fuel-core
that referenced
this issue
Oct 7, 2024
Related issues: - FuelLabs/fuel-core#1236 This PR adds a new CLI flag to enable the Relayer service `--enable-relayer`, and disable the Relayer service by default. When supplying the `--enable-relayer` flag, the `--relayer` argument becomes mandatory, and omitting it is an error. Similarly, providing a `--relayer` argument without the `--enable-relayer` flag is an error. Lastly, providing the `--keypair` or `--network` arguments will also produce an error if the `--enable-p2p` flag is not set.
crypto523
added a commit
to crypto523/fuel-core
that referenced
this issue
Oct 7, 2024
Related issues: - FuelLabs/fuel-core#1236 This PR adds conditional support for loading a local `.env` for environment variables. This support is only enabled when compiling the client binary with the `env` feature or when passing `--all-features` to Cargo. This is not enabled by default for production environments. Users can add a `.env` to the root directory of their local copy of their Fuel node (or wherever their working directory is). This helps users provide CLI arguments in a way that is more convenient and more secure than entering these values in an IDE directly: - Users can reuse environment variables across IDEs (e.g., VS Code and CLion) and IDE configurations seamlessly, rather than specifying them in each IDE specific configuration - Users can avoid putting secrets in shared commands or configurations - CLion users can greatly shorten their `run` commands, which is helpful since the configuration window does not word wrap long commands The `.env` is also added to `.gitignore` to prevent users from uploading individual environment configurations that may include secrets. This approach acts as a sort of stop gap for handling secrets before we have SOPS. This PR also renames the internal `eth_client` component of the relayer configuration to `relayer`. This allow users to use the environment variable name `RELAYER` to supply this value. Prior to this, the CLI expected an environment variable called `ETH_CLIENT`, even though the CLI argument is named `relayer`. Note: Due to the order in which the initialization functions are called, we cannot supply `RUST_LOG` in the .env file; this has to be provided elsewhere or directly to Cargo.
crypto523
added a commit
to crypto523/fuel-core
that referenced
this issue
Oct 7, 2024
Related issues: - Closes FuelLabs/fuel-core#1236 This PR adds documentation on debugging. --------- Co-authored-by: Brandon Kite <brandonkite92@gmail.com> Co-authored-by: Green Baneling <XgreenX9999@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The text was updated successfully, but these errors were encountered: