Files that changed from the base of the PR and between 623682b and 79d4736.

• hopr/hopr-lib/src/lib.rs (1 hunks)
• hoprd/rest-api/src/node.rs (3 hunks)

hoprd/rest-api/src/node.rs (3)

289-289: LGTM: Addition of provider field to NodeInfoResponse

The provider field has been correctly added to the NodeInfoResponse struct. This addition aligns with the PR objective to include the provider URL in the info endpoint response.

---

Line range hint 1-433: Summary of changes

The changes to add the provider field to the NodeInfoResponse and include it in the /info endpoint response have been implemented correctly. The modifications are consistent across the struct definition, example JSON, and the info function.

A few minor suggestions have been made:

1. Consider using a more generic placeholder for the provider URL in the example JSON.
2. Verify the error handling of the get_provider() method to ensure robustness.

Overall, the implementation aligns well with the PR objectives to enhance the /info endpoint by adding the provider URL to its response.

---

354-354: LGTM: Addition of provider field in info function

The provider field has been correctly added to the NodeInfoResponse creation in the info function, using hopr.get_provider(). This is consistent with the PR objectives.

However, please verify the error handling of get_provider(). If this method can fail, consider adding appropriate error handling to ensure robustness.

To verify the implementation and error handling of get_provider(), please run the following script:

✅ Verification successful

LGTM: Addition of provider field in info function

The provider field has been correctly added to the NodeInfoResponse creation in the info function, using hopr.get_provider(). The get_provider() method ensures a default provider is set, maintaining robustness.

If the fallback to a default provider meets the application's requirements, no further action is needed. Otherwise, consider implementing more explicit error handling to manage potential failures.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the implementation of get_provider() method

# Search for the get_provider method definition
echo "Searching for get_provider method definition:"
rg --type rust "fn\s+get_provider" -A 10

# Search for potential error handling in get_provider method
echo "Searching for error handling in get_provider method:"
rg --type rust "fn\s+get_provider" -A 20 | rg "Result|Error|unwrap|expect"

Length of output: 3295

hopr/hopr-lib/src/lib.rs (3)

681-687: LGTM: New get_provider method looks good.

The new get_provider method has been implemented correctly. It returns the provider URL, falling back to the default provider if a custom one is not specified. This aligns with the PR objectives of enhancing the /info endpoint by adding the provider URL to its response.

A few observations:

1. The method correctly uses the unwrap_or pattern to handle the case when self.cfg.chain.provider is None.
2. The return type is String, which is appropriate for a URL.
3. The method is public, allowing it to be used by other parts of the codebase or external consumers.

---

Line range hint 1-687: Summary: get_provider method successfully implemented.

The new get_provider method has been added to the Hopr struct implementation, fulfilling the requirement to enhance the /info endpoint with the provider URL. The implementation is correct and consistent with the existing codebase structure.

Key points:

1. The method correctly handles both custom and default provider scenarios.
2. It's placed logically among other getter methods in the Hopr implementation.
3. The change is isolated and doesn't directly impact other parts of this file.

To ensure full implementation of the feature:

1. Verify that this method is called when constructing the /info endpoint response.
2. Consider adding unit tests for the new method.
3. Update relevant documentation to reflect this new capability.

---

681-687: Verify usage of the new get_provider method.

The get_provider method has been added successfully, but it's not used within this file. To ensure it's being utilized as intended for the /info endpoint enhancement:

1. Verify that this method is called in the appropriate place to include the provider URL in the info API response.
2. Consider adding unit tests for this new method to ensure its correctness.

To check the usage of the new method across the codebase, run the following script:

✅ Verification successful

get_provider method is correctly utilized in the /info endpoint.

The get_provider method is used in hoprd/rest-api/src/node.rs within the NodeInfoResponse to include the provider URL in the API response.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for usage of the get_provider method
rg --type rust 'get_provider\('

Length of output: 175

---

Script:

#!/bin/bash
# Extract the context of the get_provider usage in rest-api/src/node.rs
rg --type rust 'get_provider\(' rest-api/src/node.rs -A10 -B10

Length of output: 125

---

Script:

#!/bin/bash
# Check if rest-api/src/node.rs exists
if [ -f rest-api/src/node.rs ]; then
    echo "rest-api/src/node.rs exists."
    # Extract the context of the get_provider usage
    rg --type rust 'get_provider\(' rest-api/src/node.rs -A10 -B10
else
    echo "rest-api/src/node.rs does not exist."
    # Search for get_provider usage in the entire codebase
    rg --type rust 'get_provider\('
fi

Length of output: 292

---

Script:

#!/bin/bash
# Check if hoprd/rest-api/src/node.rs exists
if [ -f hoprd/rest-api/src/node.rs ]; then
    echo "hoprd/rest-api/src/node.rs exists."
    # Extract the context of the get_provider usage
    rg --type rust 'get_provider\(' hoprd/rest-api/src/node.rs -A10 -B10
else
    echo "hoprd/rest-api/src/node.rs does not exist."
    # Search for get_provider usage in the entire codebase
    rg --type rust 'get_provider\('
fi

Length of output: 1348

Files that changed from the base of the PR and between 79d4736 and 806392e.

• hopr/hopr-lib/src/lib.rs (1 hunks)

hopr/hopr-lib/src/lib.rs (3)

681-687: LGTM: Provider retrieval method implemented correctly.

The get_provider method has been implemented as requested. It correctly returns the custom provider if specified, otherwise falling back to the default provider from the chain configuration.

---

681-687: Summary: Implementation meets requirements, consider suggested improvements.

The get_provider method has been successfully implemented, meeting the requirements of the PR objectives and linked issues. The changes are minimal and low-risk. To complete this feature:

1. Update the /info API endpoint to include the provider URL in its response.
2. Verify the implementation using the provided script.
3. Consider the suggested performance optimization if get_provider is expected to be called frequently.

Once these steps are completed, this PR will fully address the enhancement requested in issue #6443.

---

681-687: Verify API endpoint update and implementation.

The get_provider method is correctly implemented and aligns with the PR objectives. However, to fully complete the feature:

1. Ensure that the /info API endpoint is updated to include the provider URL in its response.
2. Verify that when a custom provider is set, it's correctly returned in the API response.
3. Confirm that when no custom provider is set, the default provider is returned in the API response.

To verify the implementation, you can use the following script:

Files that changed from the base of the PR and between 806392e and 790ad87.

• hopr/hopr-lib/src/lib.rs (1 hunks)

Files that changed from the base of the PR and between 790ad87 and 1d2da6a.

• hopr/hopr-lib/src/lib.rs (1 hunks)
• hoprd/rest-api/src/node.rs (3 hunks)

hoprd/rest-api/src/node.rs (3)

301-301: LGTM: Provider field added to NodeInfoResponse struct

The addition of the provider: String field to the NodeInfoResponse struct is correct and consistent with the changes in the example JSON schema. This change aligns with the PR objective to include the provider URL in the info endpoint response.

---

Line range hint 273-366: Summary: Provider URL successfully added to info endpoint

The changes in this file successfully implement the addition of the provider URL to the info endpoint response. The modifications are consistent across the NodeInfoResponse struct definition, example schema, and the info function implementation. These changes align well with the PR objectives and address the requirements outlined in the linked issue #6443.

Key points:

1. The provider field has been added to the NodeInfoResponse struct.
2. The example JSON schema has been updated to include the provider field.
3. The info function now populates the provider field using the hopr.get_provider() method.

Overall, the implementation looks correct and achieves the desired outcome of enhancing the /info endpoint by including the provider URL in its response.

---

366-366: LGTM: Provider field populated in info function

The addition of provider: hopr.get_provider() in the NodeInfoResponse construction is correct and aligns with the PR objectives. This change ensures that the provider URL is included in the info endpoint response.

To ensure the get_provider() method is correctly implemented, please run the following verification script:

✅ Verification successful

: Provider field correctly implemented in info function

The implementation of provider: hopr.get_provider() in the NodeInfoResponse is properly defined and aligns with the get_provider method in the Hopr struct. No issues found.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the implementation of the get_provider() method in the Hopr struct.

# Test: Search for the get_provider method definition
rg --type rust 'fn get_provider.*\{' -A 10

Length of output: 1416

hopr/hopr-lib/src/lib.rs (2)

682-688: LGTM! Implementation aligns with PR objectives.

The get_provider method correctly implements the logic to return the provider URL, aligning with the PR objectives. It appropriately uses the custom provider if available, otherwise falling back to the default provider.

---

682-688: Verify usage of get_provider method in the codebase.

The get_provider method has been implemented correctly. To ensure it's properly integrated and used as intended:

Run the following script to check its usage across the codebase:

This will help verify that the method is being used as expected, particularly in relation to the /info endpoint mentioned in the PR objectives.

✅ Verification successful

Usage of get_provider method verified.

The get_provider method is correctly utilized in hoprd/rest-api/src/node.rs as part of the /node/info endpoint implementation.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check usage of get_provider method across the codebase

# Test: Search for get_provider method calls
echo "Searching for get_provider method calls:"
rg --type rust "\.get_provider\(\)"

# Test: Search for potential info endpoint implementations
echo "Searching for potential info endpoint implementations:"
rg --type rust "info.*endpoint|/info"

Length of output: 10234