Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: fix status_code being logged as string instead of number in logs #5850

Merged
merged 1 commit into from
Sep 11, 2024

Conversation

SanchithHegde
Copy link
Member

Type of Change

  • Bugfix
  • New feature
  • Enhancement
  • Refactoring
  • Dependency updates
  • Documentation
  • CI/CD

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() and router::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 the Display implementation to log the status code also caused the same problem. The fix was to not provide any sigil (? or %) and let tracing 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?

  1. Create a successful payment using Postman (basically any request that includes a connector call).

  2. Search logs, filtering by the request ID and searching for call_connector_api.

    Previously, the status code was logged as a string:

    Screenshot of status code logged as string

    With this fix, the status code is correctly logged as a number:

    Screenshot of status code logged as 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).

  3. 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:

    Screenshot of outgoing webhook status code logged as string

    After:

    Screenshot of outgoing webhook status code logged as number

Checklist

  • I formatted the code cargo +nightly fmt --all
  • I addressed lints thrown by cargo clippy
  • I reviewed the submitted code
  • I added unit tests for my changes where possible

@SanchithHegde SanchithHegde added A-framework Area: Framework C-bug Category: Bug S-waiting-on-review Status: This PR has been implemented and needs to be reviewed labels Sep 10, 2024
@SanchithHegde SanchithHegde self-assigned this Sep 10, 2024
@SanchithHegde SanchithHegde requested review from a team as code owners September 10, 2024 21:00
Copy link

semanticdiff-com bot commented Sep 10, 2024

Review changes with SemanticDiff.

Analyzed 2 of 2 files.

Filename Status
✔️ crates/router/src/services/api.rs Analyzed
✔️ crates/router/src/core/webhooks/outgoing.rs Analyzed

@SanchithHegde SanchithHegde added this to the September 2024 Release milestone Sep 10, 2024
@Gnanasundari24 Gnanasundari24 added this pull request to the merge queue Sep 11, 2024
Merged via the queue into main with commit 75e8f35 Sep 11, 2024
14 checks passed
@Gnanasundari24 Gnanasundari24 deleted the fix-string-status-code-in-logs branch September 11, 2024 06:25
@SanchithHegde SanchithHegde removed the S-waiting-on-review Status: This PR has been implemented and needs to be reviewed label Sep 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-framework Area: Framework C-bug Category: Bug
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants