fix: fix status_code
being logged as string instead of number in logs
#5850
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Type of Change
Description
This PR fixes a bug with the
status_code
field being logged as a string instead of a number in JSON logs. This was primarily happening in two functions:router::services::api::call_connector_api()
androuter::core::webhooks::outgoing::error_response_handler()
.The bug occurred due to the
Debug
implementation of the field being used to log the values (with the?
sigil). Using the%
sigil to use theDisplay
implementation to log the status code also caused the same problem. The fix was to not provide any sigil (?
or%
) and lettracing
automatically format the status code.Motivation and Context
This PR fixes a bug with status codes being sometimes logged as strings, which also caused issues with Elasticsearch being unable to index the field correctly.
How did you test it?
Create a successful payment using Postman (basically any request that includes a connector call).
Search logs, filtering by the request ID and searching for
call_connector_api
.Previously, the status code was logged as a string:
With this fix, the status code is correctly logged as a number:
As part of this change, the
url
field in the log message also loses one set of double quotes (and is no longer escaped as a result).If the webhook URL is configured incorrectly in the business profile (such that the URL returns a non-2xx status code when a webhook is sent) and the payment created triggers a webhook, then the error log should also have the status code logged as a number (logs can be filtered with request ID and the message
Ignoring error when sending webhook to merchant
):Before:
After:
Checklist
cargo +nightly fmt --all
cargo clippy