• go.mod

• cmd/blobstream/base/config.go (3 hunks)
• cmd/blobstream/bootstrapper/cmd.go (4 hunks)
• cmd/blobstream/bootstrapper/config.go (4 hunks)
• cmd/blobstream/deploy/cmd.go (3 hunks)
• cmd/blobstream/deploy/config.go (4 hunks)
• cmd/blobstream/keys/evm/config.go (4 hunks)
• cmd/blobstream/keys/evm/evm.go (8 hunks)
• cmd/blobstream/keys/p2p/config.go (2 hunks)
• cmd/blobstream/keys/p2p/p2p.go (5 hunks)
• cmd/blobstream/orchestrator/cmd.go (6 hunks)
• cmd/blobstream/orchestrator/config.go (5 hunks)
• cmd/blobstream/relayer/cmd.go (6 hunks)
• cmd/blobstream/relayer/config.go (5 hunks)
• e2e/scripts/deploy_blobstream_contract.sh (1 hunks)
• orchestrator/orchestrator.go (4 hunks)
• p2p/querier.go (2 hunks)
• relayer/relayer.go (2 hunks)

• cmd/blobstream/keys/p2p/p2p.go
• orchestrator/orchestrator.go
• p2p/querier.go
• relayer/relayer.go

cmd/blobstream/relayer/cmd.go (2)

• 2-7: Removal of the "os" import is appropriate if it's no longer used after the logger changes.

• 114-125: > Note: This review was outside of the patch, so it was mapped to the patch with the greatest overlap. Original lines [97-212]

The changes to use base.GetLogger for logger instantiation and the elevation of certain log messages from "Debug" to "Info" level are consistent with the pull request's goal of enhancing the logging system.

cmd/blobstream/deploy/config.go (3)

• 29-34: The addition of log level and format flags to the deploy command is a good enhancement for user customization. Ensure that the help text and documentation are updated to reflect these new flags.

• 43-47: The deployConfig struct has been correctly updated to include logLevel and logFormat. This aligns with the goal of enhancing the logging system.

• 104-119: > Note: This review was outside of the patch, so it was mapped to the patch with the greatest overlap. Original lines [50-132]

The parseDeployFlags function has been updated to handle the new log-related flags. Ensure that the parsing of these flags is consistent with the expected input formats and that any necessary validation is performed.

Overall, the changes made in this file are consistent with the pull request's goal of enhancing the logging system. It is important to ensure that the rest of the codebase is compatible with these changes, especially where the deployConfig struct is used.

cmd/blobstream/keys/evm/config.go (3)

• 45-65: The error handling is consistent and returns early in case of an error, which is good practice. However, ensure that the GetLogLevelFlag and GetLogFormatFlag functions do not return a valid value when an error occurs, to avoid any potential misuse of the returned values.

• 73-78: The addition of new flags for logging is consistent with the rest of the changes in the pull request. Ensure that the help text for the flags is clear and informative for the end-user.

• 107-125: The parsing logic for the new passphrase configuration is consistent with the parsing logic for the keys configuration. Ensure that the GetLogLevelFlag and GetLogFormatFlag functions are thoroughly tested to handle edge cases and invalid inputs.

cmd/blobstream/keys/p2p/config.go (2)

• 45-46: The error handling is consistent and returns the error to the caller, which is good practice. However, ensure that the caller of parseKeysConfigFlags handles these errors appropriately.

• 38-51: The parsing of flags and creation of the KeysConfig struct is done correctly. It's good to see that the log level and format are being retrieved using dedicated functions, which likely include validation logic.

cmd/blobstream/bootstrapper/cmd.go (5)

• 8-12: The addition of the base package import is necessary for the new logging system. Ensure that the base package provides the expected GetLogger function.

• 51-53: Replacing direct logger instantiation with base.GetLogger is a good practice for consistency and maintainability. Ensure that all error handling is consistent with the rest of the codebase.

• 55-55: Using the logger obtained from base.GetLogger to log the start of the bootstrapper node is a good practice for consistent logging.

• 150-152: The same change as above, ensuring that the logger is consistently used across different commands.

• 147-153: Ensure that the parseInitFlags function is updated to handle the new logLevel and logFormat flags.

cmd/blobstream/relayer/config.go (3)

• 83-87: Added flags for log level and format. Ensure that the corresponding base package functions for AddLogLevelFlag and AddLogFormatFlag are implemented correctly and handle the expected input values.

• 229-242: Parsing of the new log level and format flags. Ensure that the base package's GetLogLevelFlag and GetLogFormatFlag functions return the expected values and handle errors appropriately.

• 274-291: Parsing of the new log level and format flags for the init command. Ensure that the base package's GetLogLevelFlag and GetLogFormatFlag functions return the expected values and handle errors appropriately.

cmd/blobstream/bootstrapper/config.go (5)

• 18-23: The addition of log level and format flags to the command is a good enhancement for user configurability. Ensure that the corresponding AddLogLevelFlag and AddLogFormatFlag functions are implemented correctly in the base package.

• 26-32: The StartConfig struct has been updated to include logLevel and logFormat. This change should be cross-checked with other parts of the code to ensure that all usages of StartConfig are updated accordingly.

• 56-78: > Note: This review was outside of the patch, so it was mapped to the patch with the greatest overlap. Original lines [34-77]

Parsing of the new flags logLevel and logFormat is handled correctly. However, ensure that the default values for these flags are set appropriately if they are not provided by the user.

• 90-94: The InitConfig struct has been similarly updated. As with StartConfig, ensure that all usages of InitConfig are updated to accommodate the new fields.

• 105-122: > Note: This review was outside of the patch, so it was mapped to the patch with the greatest overlap. Original lines [96-122]

The parsing logic for InitConfig mirrors that of StartConfig. The same considerations apply here regarding default values and error handling.

cmd/blobstream/keys/evm/evm.go (8)

• 9-16: The import of the base package and the use of base.GetLogger function is a good practice for maintaining consistency in logger instantiation across different modules. This change centralizes the logger configuration and instantiation, which can make it easier to manage logging behavior from a single location.

• 59-68: The error handling after attempting to get the logger is correct. If an error occurs while getting the logger, the function returns early, which is a standard practice for error handling in Go.

• 155-164: Similar to the previous hunk, the error handling after attempting to get the logger is correct and consistent with Go's idiomatic error handling practices.

• 203-212: Again, the error handling after attempting to get the logger is correct. It's good to see consistency in error handling across different functions.

• 297-306: The error handling after attempting to get the logger is correct. The function returns early if an error is encountered, which is the expected behavior.

• 386-395: The error handling after attempting to get the logger is correct. The function returns early if an error is encountered, which is the expected behavior.

• 454-463: The error handling after attempting to get the logger is correct. The function returns early if an error is encountered, which is the expected behavior.

• 538-547: The error handling after attempting to get the logger is correct. The function returns early if an error is encountered, which is the expected behavior.

Overall, the changes in this file are consistent and follow good practices for error handling and logger instantiation. The use of a centralized logger configuration function (base.GetLogger) is a good approach to ensure that all parts of the application use the logger in a consistent way.

cmd/blobstream/base/config.go (2)

• 81-86: The addition of new flags for log level and format is a good enhancement for user customization. Ensure that the default values provided are consistent with the expected behavior of the application and that they are documented appropriately for the users.

• 97-103: The function GetLogFormatFlag retrieves the log format flag value. It is important to ensure that the default value 'plain' is handled correctly in the logging setup and that the application supports the formats specified.

cmd/blobstream/orchestrator/config.go (4)

• 61-66: The addition of LogLevel and LogFormat flags to the addOrchestratorFlags function is a good enhancement for user customization. Ensure that the base package's functions AddLogLevelFlag and AddLogFormatFlag are implemented correctly and handle the flag values as expected.

• 75-80: The StartConfig struct has been correctly updated to include LogLevel and LogFormat. This change will require that all parts of the code that instantiate StartConfig are updated to handle these new fields.

• 166-181: Parsing the new flags in parseOrchestratorFlags is done correctly. It's important to ensure that the default values for LogLevel and LogFormat are set appropriately if they are not provided by the user.

• 211-230: > Note: This review was outside of the patch, so it was mapped to the patch with the greatest overlap. Original lines [197-228]

The InitConfig struct and parseInitFlags function have been updated to handle the new logLevel and logFormat flags. Ensure that the InitConfig struct is used appropriately in the initialization process and that the log level and format are applied correctly.

Overall, the changes made in this file are consistent with the goal of enhancing the logging system. It's important to ensure that the new flags are documented and that users are aware of how to use them. Additionally, testing should be conducted to verify that the logging behaves as expected when the flags are set to different values.

cmd/blobstream/orchestrator/cmd.go (7)

• 3-7: Removal of the "os" package import is appropriate if it's no longer used in this file.

Hunk 1

No specific issues or changes to comment on.

Hunk 2

• 45-54: The code changes here seem to be related to configuration loading and error handling, which is appropriate for the initialization of the command. Ensure that the LoadFileConfiguration function is correctly implemented and tested.

Hunk 3

• 64-67: The use of base.GetLogger to initialize the logger with the specified log level and format is a good practice as it centralizes the logger creation logic, which can be reused across different modules.

• 69-73: Elevating the log level from debug to info for the initialization message is a good practice to ensure important information is visible by default.

Hunk 4

• 145-148: The log message indicating the start of the orchestrator is now at the info level, which is appropriate for such a significant event in the application lifecycle.

Hunk 5

• 170-173: Ensure that config.logLevel and config.logFormat are correctly named and accessed. If these are fields of the config struct, they should be capitalized (e.g., config.LogLevel and config.LogFormat) to be exported and accessible outside of their package.

• 175-176: The initialization of the store with the NeedDataStore flag set to true is consistent with the application's requirements for a data store.

Overall, the changes in this file align with the pull request's goal of enhancing the logging system and improving error handling. Ensure that all new configurations are documented and that the changes are thoroughly tested, especially in different logging scenarios.

cmd/blobstream/deploy/cmd.go (1)

• 2-11: The import section has been updated to include the new base package for logging. Ensure that the new logging system is compatible with the existing codebase and that the transition to the new logger is seamless.

e2e/scripts/deploy_blobstream_contract.sh (1)

• 78-78: The use of awk to extract the contract address assumes a specific output format. Ensure that the output format of the deployment command (/bin/blobstream deploy) is consistent and that the field index ($6) corresponds to the correct part of the output containing the "deployed" keyword and contract address. If the output format changes, this line will need to be updated accordingly.

• e2e/scripts/deploy_blobstream_contract.sh (1 hunks)

• e2e/scripts/deploy_blobstream_contract.sh