[david-ruiz-cko]

Summary

Security hardening (reported internally) in the authentication client, error handling and request logging. No public API is removed; one exception type changes on the OAuth token request (see Breaking changes). Token request client errors (4xx) raise CheckoutAuthorizationException; server errors keep their Faraday class, without request data.

Changes

• lib/checkout_sdk/api_client.rb: error handling for requests and file uploads; request log lines.
• lib/checkout_sdk/events/events_client.rb: retrieve_all_event_types builds its query with URI.encode_www_form.
• spec/checkout_sdk/oauth_sdk_credentials_spec.rb: new, OAuth token responses (success, 4xx, 5xx, timeout).
• spec/checkout_sdk/api_client_spec.rb: request logging and error data tests.
• spec/checkout_sdk/checkout_utils_spec.rb: new, loggable_path.
• spec/checkout_sdk/events/events_client_spec.rb: new, event types query.
• lib/checkout_sdk/checkout_utils.rb: shared helpers for log lines, exception messages and error data; default clients configure raise_error with include_request: false.
• lib/checkout_sdk/error.rb: both exceptions build their message with the shared helper; CheckoutAuthorizationException exposes http_metadata.
• lib/checkout_sdk/oauth_sdk_credentials.rb: token request errors handled through the shared helpers.
• README.md: custom HTTP client note on include_request: false (Faraday 2.7.11 or later).

API Reference

None.

Breaking changes ⚠️

• Exception message text only; no exception classes change.
• OAuth token request: CheckoutAuthorizationException reads The OAuth token response status code (<status>) does not indicate success. followed by the response details, or The OAuth token request failed without a response. when there is no response.
• API errors: CheckoutApiException details are limited to 256 characters, and nested values render as plain values.
• Migration: read http_metadata / error_details instead of parsing messages.

Tests

• Existing tests pass (unit suite and rubocop lib; integration tests run in CI against the sandbox)
• Serialization tests cover every new or changed property (no request or response properties changed)
• README updated if documented usage changed (documented usage unchanged)

Related

None.

[agent-wall-e]

🔴 Risk Classification: MAJOR

Approval route: AI Review + Human Approval Required
Rollback controls: Change-freeze window + documented rollback plan

Classification reasons

• security_sensitive_path:lib/checkout_sdk/oauth_sdk_credentials.rb
• security_sensitive_path:spec/checkout_sdk/oauth_sdk_credentials_spec.rb

Operational gates

• ✅ jira_ticket (INT-1767)
• ✅ independent_review

Files analysed: 9

---

_{wall-e 2026.06.19-02 · policy 6b4ce2b3b45a…}

[agent-wall-e]

🔬 Debug — why this classification?

Each reason code emitted by the classifier, its source clause in the AI in SDLC Control Framework, and what it means.

Reason code	Kind	Clause	Meaning
security_sensitive_path — lib/checkout_sdk/oauth_sdk_credentials.rb	classifying	§2.1 M4/M5	Path matched a sensitive pattern (auth, secrets, crypto, PCI, migrations, network IaC).
security_sensitive_path — spec/checkout_sdk/oauth_sdk_credentials_spec.rb	classifying	§2.1 M4/M5	Path matched a sensitive pattern (auth, secrets, crypto, PCI, migrations, network IaC).

Kinds:

• classifying — this rule contributed to the chosen tier.
• informational — context only; did not by itself decide the tier.

See issue #3 for the proposal to formalise this map as Appendix A of the standards doc.

_{wall-e 2026.06.19-02 · debug}

[agent-wall-e]

🟠 Advisory review: Concerns worth a look

This PR needs a human approval. Before you give it, these are the things I'd want resolved.

The PR adds OAuth error hardening, log-injection prevention, and request-data scrubbing from raised exceptions. The logic is mostly correct and well-tested, but there are two concrete problems: a gap in the raise_without_request_data guard that allows a frozen response to silently skip the scrub, and a missing escape for Unicode line/paragraph separators in loggable_path despite a test that documents the gap.

Concerns

• In checkout_utils.rb, loggable_path only strips [[:cntrl:]] (C0/C1 control chars), but the spec for Unicode line separators (U+2028, U+2029) expects them to be escaped as \u2028/\u2029 — those codepoints are NOT matched by [[:cntrl:]] in Ruby, so that test will fail and the log-injection vector it guards against (U+2028/U+2029 are treated as line terminators by some log consumers) remains open.
• In api_client.rb, raise_without_request_data silently skips removing the request data when error.response is a frozen Hash (the !error.response.frozen? guard causes it to fall through without raising or duping). A frozen response would still expose request data, defeating the stated security goal; the correct fix is to dup the hash before deletion when it is frozen.
• In oauth_sdk_credentials.rb, the rescue Faraday::ConnectionFailed branch still raises CheckoutArgumentException with e.wrapped_exception as the message, which could contain connection details (e.g. the authorization URI); this is a minor inconsistency with the stated hardening intent but worth a conscious decision.
• The loggable_path spec itself for Unicode separators (line 20-22 of checkout_utils_spec.rb) expects escaped output (\u2028/\u2029) that the current regex implementation cannot produce, confirming the test would fail against the shipped code.

---

_{This is not an approval. wall-e cannot auto-approve this PR — it is an opinion to help whoever does. Advisory review · us.anthropic.claude-sonnet-4-6 · wall-e 2026.06.19-02}

[agent-wall-e]

🔴 Risk Classification: MAJOR

Approval route: AI Review + Human Approval Required
Rollback controls: Change-freeze window + documented rollback plan

Classification reasons

• security_sensitive_path:lib/checkout_sdk/oauth_sdk_credentials.rb
• security_sensitive_path:spec/checkout_sdk/oauth_sdk_credentials_spec.rb

Operational gates

• ✅ jira_ticket (INT-1767)
• ✅ independent_review

Files analysed: 10

---

_{wall-e 2026.06.19-02 · policy 6b4ce2b3b45a…}

[agent-wall-e]

🔬 Debug — why this classification?

Each reason code emitted by the classifier, its source clause in the AI in SDLC Control Framework, and what it means.

Reason code	Kind	Clause	Meaning
security_sensitive_path — lib/checkout_sdk/oauth_sdk_credentials.rb	classifying	§2.1 M4/M5	Path matched a sensitive pattern (auth, secrets, crypto, PCI, migrations, network IaC).
security_sensitive_path — spec/checkout_sdk/oauth_sdk_credentials_spec.rb	classifying	§2.1 M4/M5	Path matched a sensitive pattern (auth, secrets, crypto, PCI, migrations, network IaC).

Kinds:

• classifying — this rule contributed to the chosen tier.
• informational — context only; did not by itself decide the tier.

See issue #3 for the proposal to formalise this map as Appendix A of the standards doc.

_{wall-e 2026.06.19-02 · debug}

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud