Skip to content

fix: log response body and status code on unmarshal failure#181

Open
15666668904 wants to merge 2 commits intolarksuite:v2_mainfrom
15666668904:v2_main
Open

fix: log response body and status code on unmarshal failure#181
15666668904 wants to merge 2 commits intolarksuite:v2_mainfrom
15666668904:v2_main

Conversation

@15666668904
Copy link
Copy Markdown

Summary

When UnmarshalRespUtil.unmarshalResp() fails to deserialize the HTTP response, the original status code and response body are silently lost, making it impossible to diagnose the root cause.

For example, when a network gateway returns HTML instead of JSON, the caller only sees:

com.google.gson.JsonSyntaxException: Expected BEGIN_OBJECT but was STRING at line 1 column 1

with no indication of what the server actually returned or what the HTTP status code was.

Changes

  • Warn on non-2xx status: Log a warning when the HTTP status code is outside the 2xx range, before attempting deserialization. This does not change the control flow — deserialization still proceeds normally (Lark API may return error details in JSON with non-2xx status).
  • Log on deserialization failure: When Gson.fromJson() throws an exception, log the HTTP status code and response body at ERROR level before re-throwing.
  • Body truncation: Response body is truncated to 500 characters in log output to prevent leaking sensitive data and log flooding.
  • Unit tests: Added TestUnmarshalRespUtil with 6 test cases covering success path, invalid JSON, string-instead-of-object, HTML response, non-2xx with valid JSON, and long body truncation.

Related Issues

Closes #163
Relates to #142, #133

Test Plan

  • All 6 unit tests pass locally (mvn surefire:test -pl larksuite-oapi -Dtest=TestUnmarshalRespUtil)
  • Existing behavior unchanged — exception is still re-thrown after logging
  • Non-2xx responses with valid JSON body still deserialize correctly

@CLAassistant
Copy link
Copy Markdown

CLAassistant commented Apr 5, 2026

CLA assistant check
All committers have signed the CLA.

When UnmarshalRespUtil.unmarshalResp() fails to deserialize the HTTP
response, the original status code and response body are silently lost,
making it impossible to diagnose the root cause (e.g. network gateway
returning HTML instead of JSON).

Changes:
- Log a warning when HTTP status code is not 2xx
- Log an error with status code and truncated body (max 500 chars) when
  JSON deserialization fails
- Add unit tests covering success, invalid JSON, non-2xx with valid JSON,
  HTML response, and body truncation scenarios

The response body is truncated to 500 characters to avoid leaking
sensitive data and to prevent log flooding.

Closes larksuite#163
Relates to larksuite#142, larksuite#133
The surefire plugin had <skipTests>true</skipTests> hardcoded in its
configuration block, which cannot be overridden by -DskipTests=false
from the command line.

Changed to use a Maven property reference <skipTests>${skipTests}</skipTests>
with a default value of true in <properties>, so that:
- Default behavior is unchanged (tests are skipped)
- Developers can run tests with: mvn test -DskipTests=false
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.

Expected BEGIN_OBJECT but was STRING at line 1 column 1 path $

2 participants