Files that changed from the base of the PR and between 0d3dd41 and 1ff034c.

• hopr/hopr-lib/src/lib.rs (1 hunks)
• hoprd/rest-api/src/lib.rs (29 hunks)
• transport/api/src/constants.rs (1 hunks)
• transport/api/src/lib.rs (2 hunks)

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

32-32: LGTM!

The addition of RESERVED_TAG_UPPER_LIMIT to the public exports is correctly done.

hoprd/rest-api/src/lib.rs (12)

27-27: Good addition of trace level logging.

Adding trace level logging enhances the granularity of the logs, which can be very useful for debugging and monitoring.

---

63-64: Simplified State struct.

The removal of the config field simplifies the State struct, which can reduce complexity. Ensure that the config field is not required elsewhere in the codebase.

---

248-252: Updated serve_swagger function signature.

The function signature change aligns with the new State struct definition. Ensure that all calls to this function are updated accordingly.

---

283-283: Simplified run_hopr_api function.

The function has been simplified by eliminating the config initialization. Ensure that the config is not needed in the function.

---

379-383: Good addition of debug logging for WebSocket communication.

Adding debug logging improves traceability of WebSocket communication, which is beneficial for debugging.

---

403-405: Good cleanup of commented-out code.

Removing commented-out code improves code readability and maintainability.

---

423-455: Good addition of handling for binary WebSocket messages and logging for unsupported commands.

Adding handling for binary WebSocket messages and logging for unsupported commands improves functionality and traceability.

---

456-465: Good addition of handling for client-closed connections and ping messages.

Adding handling for client-closed connections and ping messages improves WebSocket functionality and traceability.

---

512-513: Good addition of InvalidApplicationTag variant to ApiErrorStatus enum.

Adding the InvalidApplicationTag variant improves error handling for invalid application tags.

---

1463-1465: Necessary imports for new functionality.

Adding import statements for AsUnixTimestamp, HalfKeyChallenge, and RESERVED_TAG_UPPER_LIMIT is necessary for the new functionality related to message handling and validation.

---

Line range hint 1567-1587: Good addition of input validation for SendMessageBodyRequest.

Adding validation for SendMessageBodyRequest and ensuring either path or hops must be specified improves input validation and error handling.

---

1738-1742: Good addition of tag validation in delete_messages function.

Adding validation to ensure the tag is above RESERVED_TAG_UPPER_LIMIT improves input validation and error handling.

Files that changed from the base of the PR and between 1ff034c and f7312ec.

• Cargo.lock is excluded by !**/*.lock

• hopr/hopr-lib/src/lib.rs (1 hunks)
• hoprd/rest-api/src/lib.rs (28 hunks)
• transport/api/src/constants.rs (1 hunks)
• transport/api/src/lib.rs (2 hunks)

transport/api/src/lib.rs (1)

414-421: Correct the validation logic for application_tag.

The validation logic should check if application_tag is greater than or equal to RESERVED_TAG_UPPER_LIMIT, not less than.

- if application_tag < RESERVED_TAG_UPPER_LIMIT {
+ if application_tag >= RESERVED_TAG_UPPER_LIMIT {

Likely invalid or redundant comment.

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

32-32: Ensure consistent export of RESERVED_TAG_UPPER_LIMIT.

The constant RESERVED_TAG_UPPER_LIMIT is correctly added to the public exports. Ensure this is consistent with its usage throughout the codebase.

hoprd/rest-api/src/lib.rs (7)

63-64: Simplified State struct.

The State struct now only contains an Arc<Hopr>. Ensure that all parts of the code that previously relied on the config field are updated accordingly.

---

248-252: Updated serve_swagger function signature.

The function signature now reflects the changes in the State struct. Ensure that the function works correctly with the updated State.

---

283-283: Simplified run_hopr_api function.

The function now initializes State without the config field. Ensure that all parts of the code that previously relied on the config field are updated accordingly.

---

379-383: Enhanced WebSocket message handling.

The WebSocket handling logic now includes better message handling and logging. Ensure that these enhancements work as expected and don't introduce any issues.

---

423-425: Explicit handling of client-closed connections.

The WebSocket handling now includes explicit handling of client-closed connections. Ensure this change is robust and doesn't introduce issues.

---

471-472: Added InvalidApplicationTag variant to ApiErrorStatus.

The new variant is correctly added to the enum. Ensure that it is used appropriately in the code.

---

1422-1424: Adjusted validation rules for path and hops fields.

The validation rules have been adjusted to ensure proper validation of path and hops fields. Ensure these adjustments are correctly implemented and don't introduce any issues.

Files that changed from the base of the PR and between 1ff034c and 9ed5394.

• hopr/hopr-lib/src/lib.rs (1 hunks)
• hoprd/rest-api/src/lib.rs (28 hunks)
• transport/api/src/constants.rs (1 hunks)
• transport/api/src/lib.rs (2 hunks)

transport/api/src/constants.rs (1)

10-14: LGTM!

The constant RESERVED_TAG_UPPER_LIMIT is defined correctly and the comment provides a clear explanation of its purpose.

transport/api/src/lib.rs (2)

52-52: LGTM!

The import of RESERVED_TAG_UPPER_LIMIT is correct.

---

414-421: Validation logic for application_tag is correct.

The validation logic ensures that the application_tag is not within the reserved range.

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

32-32: LGTM!

The constant RESERVED_TAG_UPPER_LIMIT is correctly added to the public exports.

hoprd/rest-api/src/lib.rs (13)

248-252: LGTM! But verify the consistency of the function signature change.

The function signature change aligns with the State struct changes.

However, ensure that all function calls to serve_swagger match the new signature.

Verification successful

---

Verified: All function calls to serve_swagger match the new signature.

The function serve_swagger is correctly called with the new signature in the relevant file.

• hoprd/rest-api/src/lib.rs: app.at("/swagger-ui/*").get(serve_swagger);

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify all function calls to `serve_swagger` match the new signature.

# Test: Search for the function usage. Expect: Only occurrences of the new signature.
rg --type rust 'serve_swagger'

Length of output: 659

---

1422-1424: LGTM! But verify the usage of the new constant RESERVED_TAG_UPPER_LIMIT.

The introduction of the RESERVED_TAG_UPPER_LIMIT constant is appropriate.

However, ensure that the new constant is used correctly in the code.

---

1726-1730: Ensure the validation logic is correct.

The validation logic for the size function is appropriate.

---

1795-1799: Ensure the validation logic is correct.

The validation logic for the pop function is appropriate.

---

1897-1901: Ensure the validation logic is correct.

The validation logic for the peek function is appropriate.

---

471-472: LGTM! But verify the usage of the new enum variant.

The addition of the InvalidApplicationTag variant seems appropriate.

However, ensure that the new variant is used correctly in the code.

Verification successful

---

The new enum variant InvalidApplicationTag is used correctly.

The variant is appropriately integrated into the error handling logic in multiple places within hoprd/rest-api/src/lib.rs.

• The InvalidApplicationTag is used in response to an invalid tag scenario where the tag is less than the RESERVED_TAG_UPPER_LIMIT.

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the usage of the new enum variant `InvalidApplicationTag`.

# Test: Search for usages of `InvalidApplicationTag` in the code.
rg --type rust 'InvalidApplicationTag'

Length of output: 613

---

Script:

#!/bin/bash
# Description: Extract surrounding lines of each match of `InvalidApplicationTag` to understand its context.

# Use ripgrep to get lines around each match for context.
rg --type rust 'InvalidApplicationTag' -A 3 -B 3

Length of output: 3190

---

1464-1467: Ensure the validation rules are correct.

The validation rules for the path and hops fields in the SendMessageBodyRequest struct are appropriate.

Verification successful

---

Validation rules for SendMessageBodyRequest struct are appropriate.

The validation rules for the path and hops fields in the SendMessageBodyRequest struct are correctly applied and make sense within their usage contexts.

• The path field is validated with #[validate(length(min = 0, max = 3))], ensuring the vector's length is between 0 and 3.
• The hops field is validated with #[validate(range(min = 0, max = 3))], ensuring the value is between 0 and 3.

These validations are enforced in the send_message function, where args.validate() is called.

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the correctness of the validation rules for the `path` and `hops` fields.

# Test: Search for usages of `SendMessageBodyRequest` struct.
rg --type rust 'SendMessageBodyRequest'

Length of output: 1017

---

Script:

#!/bin/bash
# Extract lines around each usage of SendMessageBodyRequest for inspection

# Extract 5 lines before and after each match to provide context
rg --type rust 'SendMessageBodyRequest' -A 5 -B 5

Length of output: 6788

---

1526-1531: Ensure the error handling is correct.

The error handling for the send_message function has been improved.

Verification successful

---

Error handling in the send_message function is correct.

The error handling for the send_message function in hoprd/rest-api/src/lib.rs is robust and appropriately uses HTTP status codes and error messages for different failure scenarios.

• Validation errors and specific condition checks return a 422 response.
• Errors from the hopr.send_message call are also handled by returning a 422 response with the error details.

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the correctness of the error handling for the `send_message` function.

# Test: Search for usages of `send_message` function.
rg --type rust 'send_message'

Length of output: 6938

---

Script:

#!/bin/bash
# Locate the implementation of the `send_message` function in `hoprd/rest-api/src/lib.rs` and display its content for analysis.
ast-grep --lang rust --pattern $'pub async fn send_message($_) -> $_ {
  $$$
}' hoprd/rest-api/src/lib.rs

Length of output: 2700

---

1943-1947: Ensure the validation logic is correct.

The validation logic for the peek_all function is appropriate.

Verification successful

Let's start by extracting the full implementation of the peek_all function and checking the definition of RESERVED_TAG_UPPER_LIMIT.

---

Validation logic is correct.

The validation logic for the peek_all function in hoprd/rest-api/src/lib.rs correctly ensures that tags below RESERVED_TAG_UPPER_LIMIT (1024) are not used. This is consistent with the intended use of RESERVED_TAG_UPPER_LIMIT.

• hoprd/rest-api/src/lib.rs lines 1943-1947: The validation logic checks if args.tag is present and less than RESERVED_TAG_UPPER_LIMIT, returning a 400 response if true.

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the correctness of the validation logic for the `peek_all` function.

# Test: Search for usages of `peek_all` function.
rg --type rust 'peek_all'

Length of output: 1402

---

Script:

#!/bin/bash
# Extracting the full implementation of the `peek_all` function from `hoprd/rest-api/src/lib.rs`
ast-grep --lang rust --pattern 'pub async fn peek_all($_) -> $_ { $$$ }'

# Searching for the definition of `RESERVED_TAG_UPPER_LIMIT` in the codebase
rg 'RESERVED_TAG_UPPER_LIMIT'

Length of output: 3242

---

283-283: LGTM! But verify the consistency of the function changes.

The function changes align with the State struct changes.

However, ensure that the changes do not impact other parts of the code.

Verification successful

---

The changes to the run_hopr_api function are consistent and do not negatively impact other parts of the code.

• host_listen is correctly formatted and passed as a string.
• cfg.as_redacted_string()? is properly used to get a redacted string representation of the configuration.
• &cfg.api is passed correctly as a reference to the API configuration.
• node is correctly initialized and passed as an Arc of hopr_lib::Hopr.
• inbox.clone() is correctly passed as a cloned Arc of hoprd_inbox::Inbox.
• ws_events_rx is correctly initialized and passed as a deactivated receiver.
• Some(msg_encoder) is correctly passed as an optional message encoder.

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify if the changes to `run_hopr_api` impact other parts of the code.

# Test: Search for usages of `run_hopr_api` function.
rg --type rust 'run_hopr_api'

Length of output: 185

---

Script:

#!/bin/bash
# Extract relevant lines of code around the usages of `run_hopr_api` in `hoprd/hoprd/src/main.rs`
rg --type rust -A 10 -B 10 'run_hopr_api' hoprd/hoprd/src/main.rs

Length of output: 1394

---

Script:

#!/bin/bash
# Extract the definitions of the arguments passed to `run_hopr_api` in `hoprd/hoprd/src/main.rs`
rg --type rust -A 5 -B 5 'let host_listen' hoprd/hoprd/src/main.rs
rg --type rust -A 5 -B 5 'cfg.as_redacted_string' hoprd/hoprd/src/main.rs
rg --type rust -A 5 -B 5 '&cfg.api' hoprd/hoprd/src/main.rs
rg --type rust -A 5 -B 5 'node' hoprd/hoprd/src/main.rs
rg --type rust -A 5 -B 5 'inbox.clone' hoprd/hoprd/src/main.rs
rg --type rust -A 5 -B 5 'ws_events_rx' hoprd/hoprd/src/main.rs
rg --type rust -A 5 -B 5 'Some(msg_encoder)' hoprd/hoprd/src/main.rs

Length of output: 9359

---

63-64: Verify the impact of removing the config field from State.

The removal of the config field simplifies the State struct, but ensure that other parts of the code that previously accessed config are updated accordingly.

---

1844-1848: Ensure the validation logic is correct.

The validation logic for the pop_all function is appropriate.

Verification successful

---

Validation logic for pop_all function is correct.

The validation logic for the tag parameter in the pop_all function is implemented appropriately. Specifically, the check in hoprd/inbox/src/inbox.rs ensures that excluded tags are handled correctly.

• hoprd/inbox/src/inbox.rs: The is_excluded_tag(&tag) check ensures excluded tags return an empty vector.

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the correctness of the validation logic for the `pop_all` function.

# Test: Search for usages of `pop_all` function.
rg --type rust 'pop_all'

Length of output: 2783

---

Script:

#!/bin/bash
# Extract the pop_all function definition from hoprd/inbox/src/ring.rs
ast-grep --lang rust --pattern 'async fn pop_all($_) -> $_ { $$$ }' hoprd/inbox/src/ring.rs

# Extract the pop_all function definition from hoprd/inbox/src/inbox.rs
ast-grep --lang rust --pattern 'async fn pop_all($_) -> $_ { $$$ }' hoprd/inbox/src/inbox.rs

Length of output: 188

---

Script:

#!/bin/bash
# Extract the pop_all function definition from hoprd/inbox/src/ring.rs
ast-grep --lang rust --pattern 'fn pop_all($_) -> $_ { $$$ }' hoprd/inbox/src/ring.rs

# Extract the pop_all function definition from hoprd/inbox/src/inbox.rs
ast-grep --lang rust --pattern 'fn pop_all($_) -> $_ { $$$ }' hoprd/inbox/src/inbox.rs

Length of output: 176

---

Script:

#!/bin/bash
# Search for the pop_all function definition in hoprd/inbox/src/ring.rs with context lines
rg 'fn pop_all' -A 10 hoprd/inbox/src/ring.rs

# Search for the pop_all function definition in hoprd/inbox/src/inbox.rs with context lines
rg 'fn pop_all' -A 10 hoprd/inbox/src/inbox.rs

Length of output: 1618

---

1697-1701: Ensure the validation logic is correct.

The validation logic for the delete_messages function is appropriate.

Verification successful

---

Validation logic is correct.

The validation logic in the delete_messages function appropriately checks if the tag is within the reserved range and returns an error if so. The implementation correctly handles the optional nature of the tag field.

• TagQueryRequest struct: hoprd/rest-api/src/lib.rs (line 1429)
• RESERVED_TAG_UPPER_LIMIT defined as 1024: transport/api/src/constants.rs
• InvalidApplicationTag error variant: hoprd/rest-api/src/lib.rs (line 468)

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the correctness of the validation logic for the `delete_messages` function.

# Test: Search for usages of `delete_messages` function.
rg --type rust 'delete_messages'

Length of output: 283

---

Script:

#!/bin/bash
# Extract the full implementation of the `delete_messages` function for detailed analysis.
ast-grep --lang rust --pattern 'pub async fn delete_messages($_) -> $_ {
    $$$
}' --json

Length of output: 1418

---

Script:

#!/bin/bash
# Extract the definitions of `TagQueryRequest`
ast-grep --lang rust --pattern 'struct TagQueryRequest {
    $$$
}' --json

# Extract the definition of `RESERVED_TAG_UPPER_LIMIT`
rg 'RESERVED_TAG_UPPER_LIMIT'

# Extract the definition of `InvalidApplicationTag`
ast-grep --lang rust --pattern 'enum ApiErrorStatus {
    $$$
}' --json

Length of output: 2718

---

Script:

#!/bin/bash
# Search for the definition of `TagQueryRequest` in the codebase to ensure the validation logic is complete.
rg 'struct TagQueryRequest'

Length of output: 95

---

Script:

#!/bin/bash
# Extract the full definition of the `TagQueryRequest` struct from `hoprd/rest-api/src/lib.rs`.
ast-grep --lang rust --pattern 'pub(crate) struct TagQueryRequest {
    $$$
}' --json

Length of output: 667