Skip to content

handle non json jtoken#52

Merged
MatteoDelOmbra merged 3 commits intomainfrom
FSPW-745-Request
Apr 16, 2026
Merged

handle non json jtoken#52
MatteoDelOmbra merged 3 commits intomainfrom
FSPW-745-Request

Conversation

@MichalFrends1
Copy link
Copy Markdown
Contributor

@MichalFrends1 MichalFrends1 commented Apr 15, 2026

Please review my changes :)

Task Update PR template

Review Checklist

  • Task version updated (x.x.0)
  • CHANGELOG.md updated
  • Solution builds
  • Warnings resolved (if possible)
  • Typos resolved
  • Tests cover new code
  • Description how to run tests locally added to README.md (if needed)
  • All tests pass locally

Summary by CodeRabbit

  • Bug Fixes

    • When JToken return format is selected and the server responds with non-JSON content, the request now returns the response body as a raw string instead of throwing an exception, while preserving the HTTP status code for downstream control flow.
  • Chores

    • Package version bumped to 1.9.0 and changelog updated.

@coderabbitai
Copy link
Copy Markdown

coderabbitai Bot commented Apr 15, 2026

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: e349d64c-2907-42f4-bbdd-da6866f0315f

📥 Commits

Reviewing files that changed from the base of the PR and between 6ac74d4 and 39c2a8a.

📒 Files selected for processing (2)
  • Frends.HTTP.Request/Frends.HTTP.Request.Tests/UnitTests.cs
  • Frends.HTTP.Request/Frends.HTTP.Request/Request.cs

Walkthrough

The PR bumps the package to 1.9.0 and changes JToken return-format handling: when the server response is non-JSON, the code now returns the raw response body string (preserving the HTTP status code) instead of throwing a JSON parse exception.

Changes

Cohort / File(s) Summary
Changelog & Project
Frends.HTTP.Request/CHANGELOG.md, Frends.HTTP.Request/Frends.HTTP.Request/Frends.HTTP.Request.csproj
Added 1.9.0 changelog entry and incremented project version to 1.9.0.
Core Implementation
Frends.HTTP.Request/Frends.HTTP.Request/Request.cs
Refactored JToken handling to read response into a raw string and use TryParseBody (content-type aware). On JSON parse failures or non-JSON content, returns raw string instead of throwing; preserves status code.
Tests
Frends.HTTP.Request/Frends.HTTP.Request.Tests/UnitTests.cs
Replaced exception-based test with RestRequest_NonJsonResponse_ShouldReturnRawStringInsteadOfThrowing; added tests for HTML and JSON endpoints asserting raw string vs JToken behavior and status code preservation.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~30 minutes

Suggested reviewers

  • MatteoDelOmbra

Poem

🐇 I hopped to the server, sniffed the stream,
If JSON's not dancing, I keep the dream—
A raw string I carry, status intact,
Version bumped, no more parse attack. 🥕

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 11.11% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (2 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title 'handle non json jtoken' directly describes the main behavioral change: allowing non-JSON responses when using JToken return format instead of throwing an exception.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
📝 Generate docstrings
  • Create stacked PR
  • Commit on current branch
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch FSPW-745-Request

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Copy Markdown

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (3)
Frends.HTTP.Request/Frends.HTTP.Request.Tests/UnitTests.cs (1)

271-292: ⚠️ Potential issue | 🟡 Minor

Please add a regression for the new parse-fallback branch.

These tests cover explicit non-JSON content types and valid JSON, but they never hit Request.cs Lines 226-230 where JToken.Parse fails and the code falls back to a raw string. That branch is part of the new behavior and should be pinned too.

As per coding guidelines, Frends.*/Frends.*.Tests/*: Confirm unit tests exist and provide at least 80% coverage.

Also applies to: 438-457

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@Frends.HTTP.Request/Frends.HTTP.Request.Tests/UnitTests.cs` around lines 271
- 292, Add a unit test that exercises the parse-fallback branch in Request.cs
(around lines 226-230) by simulating a response whose Content-Type suggests JSON
(e.g., "application/json") but whose body is invalid JSON so JToken.Parse
throws; in the test (e.g., alongside
RestRequest_NonJsonResponse_ShouldReturnRawStringInsteadOfThrowing in
Frends.HTTP.Request.Tests/UnitTests.cs) call HTTP.Request with headers
containing application/json, a response body that is not valid JSON, and assert
that result.Body is a string (ClassicAssert.IsInstanceOf<string>), that the
string contains the original raw response content, and that result.StatusCode
equals the expected code (e.g., 200), thereby pinning the fallback behavior.
Frends.HTTP.Request/Frends.HTTP.Request/Request.cs (2)

62-66: ⚠️ Potential issue | 🔴 Critical

Update the Result class to include required properties before merging.

The Result class is missing required properties per coding guidelines. Add:

  • Success (bool) property
  • Error object with Message and AdditionalInfo properties

This PR cannot merge until Frends.HTTP.Request/Frends.HTTP.Request/Definitions/Result.cs implements these required members for task result classes.

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@Frends.HTTP.Request/Frends.HTTP.Request/Request.cs` around lines 62 - 66, The
Result class in Definitions/Result.cs is missing required members; add a public
bool Success { get; set; } and a public ErrorInfo Error { get; set; } (where
ErrorInfo is a new public class with string Message { get; set; } and string
AdditionalInfo { get; set; }) to the Result class so the Request method can
return the expected shape; ensure both classes are public with get/set accessors
and any JSON/serialization attributes used in the project are applied
consistently.

68-70: ⚠️ Potential issue | 🟡 Minor

Use ArgumentException instead of ArgumentNullException for empty-string validation.

Line 70 passes the custom message as the paramName parameter to ArgumentNullException, which violates CA2208. This is an empty-string check, not a null-argument check, so ArgumentException is the correct exception type.

Proposed fix
-            if (string.IsNullOrEmpty(input.Url)) throw new ArgumentNullException("Url can not be empty.");
+            if (input == null) throw new ArgumentNullException(nameof(input));
+            if (string.IsNullOrEmpty(input.Url)) throw new ArgumentException("Url can not be empty.", nameof(input));
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@Frends.HTTP.Request/Frends.HTTP.Request/Request.cs` around lines 68 - 70,
Replace the empty-string check that throws ArgumentNullException with an
ArgumentException and supply the parameter name properly; for the check in
Request.cs where you validate input.Url, change the throw to something like:
throw new ArgumentException("Url cannot be empty.", nameof(input.Url)) so the
message is the first argument and the parameter name is passed as the second
(use nameof(input.Url) or "Url" as the paramName).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@Frends.HTTP.Request/Frends.HTTP.Request.Tests/UnitTests.cs`:
- Around line 414-435: The test
RestRequest_NonJsonErrorResponse_ShouldReturnRawStringWithStatusCode is
misleading because it hits the 200 /html endpoint; either change the test to
actually exercise a non-2xx non-JSON error response or rename it to reflect the
200 success path. Fix option A: update Input.Url to a non-2xx, non-JSON endpoint
(e.g. use an endpoint that returns 500/plain-text such as $"{BasePath}/error" or
similar) so ThrowExceptionOnErrorResponse = false is exercised and assertions
still check StatusCode and raw Body; Fix option B: if you intend to test the 200
HTML response, rename the test method to
RestRequest_HtmlResponse_ShouldReturnRawStringWithStatusCode and keep assertions
unchanged. Ensure you update the TestMethod attribute name and any references to
Input/Options accordingly.

---

Outside diff comments:
In `@Frends.HTTP.Request/Frends.HTTP.Request.Tests/UnitTests.cs`:
- Around line 271-292: Add a unit test that exercises the parse-fallback branch
in Request.cs (around lines 226-230) by simulating a response whose Content-Type
suggests JSON (e.g., "application/json") but whose body is invalid JSON so
JToken.Parse throws; in the test (e.g., alongside
RestRequest_NonJsonResponse_ShouldReturnRawStringInsteadOfThrowing in
Frends.HTTP.Request.Tests/UnitTests.cs) call HTTP.Request with headers
containing application/json, a response body that is not valid JSON, and assert
that result.Body is a string (ClassicAssert.IsInstanceOf<string>), that the
string contains the original raw response content, and that result.StatusCode
equals the expected code (e.g., 200), thereby pinning the fallback behavior.

In `@Frends.HTTP.Request/Frends.HTTP.Request/Request.cs`:
- Around line 62-66: The Result class in Definitions/Result.cs is missing
required members; add a public bool Success { get; set; } and a public ErrorInfo
Error { get; set; } (where ErrorInfo is a new public class with string Message {
get; set; } and string AdditionalInfo { get; set; }) to the Result class so the
Request method can return the expected shape; ensure both classes are public
with get/set accessors and any JSON/serialization attributes used in the project
are applied consistently.
- Around line 68-70: Replace the empty-string check that throws
ArgumentNullException with an ArgumentException and supply the parameter name
properly; for the check in Request.cs where you validate input.Url, change the
throw to something like: throw new ArgumentException("Url cannot be empty.",
nameof(input.Url)) so the message is the first argument and the parameter name
is passed as the second (use nameof(input.Url) or "Url" as the paramName).
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: b32b2bd4-9dcb-4d5e-8038-91f633ecee0a

📥 Commits

Reviewing files that changed from the base of the PR and between 7b744d4 and 6ac74d4.

📒 Files selected for processing (4)
  • Frends.HTTP.Request/CHANGELOG.md
  • Frends.HTTP.Request/Frends.HTTP.Request.Tests/UnitTests.cs
  • Frends.HTTP.Request/Frends.HTTP.Request/Frends.HTTP.Request.csproj
  • Frends.HTTP.Request/Frends.HTTP.Request/Request.cs

Comment thread Frends.HTTP.Request/Frends.HTTP.Request.Tests/UnitTests.cs
@MatteoDelOmbra MatteoDelOmbra merged commit 1ab0761 into main Apr 16, 2026
7 checks passed
@MatteoDelOmbra MatteoDelOmbra deleted the FSPW-745-Request branch April 16, 2026 05:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants