A CI check can pass while its report is broken if the check counts fields that have silently disappeared. In this incident, the author of DocsWatcher traced empty JSON finding objects in a GraalVM native binary to missing reflection metadata for Jackson. The JVM tests passed, and a native smoke test checked only the exit code—not the report contents.
How could a check pass when its JSON findings were empty?
DocsWatcher scans code for API calls with announced shutdown dates, including OpenAI models and Stripe API versions. Its GitHub Action runs the CLI, reads its JSON report, counts findings marked breaking, and fails the step if that count is above zero.
As an Amazon Associate I earn from qualifying purchases.
According to the author’s incident account, the native executable emitted an empty object for each finding. The Action therefore had no severity field to count and treated the report as having no breaking findings. The green result reflected what the check could read, not whether the report was complete.
Why did the native executable lose the fields?
The author attributed the serialization failure to GraalVM Native Image’s closed-world reachability model. Jackson accessed Java record methods reflectively, but the Finding record’s accessors had not been registered for reflection in the native build. Without that metadata, the native executable could produce finding objects without their expected fields.
#1 Best Overall
The reported fix was reachability metadata listing the record accessors, including severity and change. The author also reported a related failure for findings with multiple locations: the Evidence[] array type needed registration too.
Why did the tests miss the defect?
JVM tests exercised a different runtime
The unit tests ran on the JVM, where the reflective access worked in this case. They did not establish that the native executable could serialize the same records correctly.
The smoke test checked status, not content
The release smoke test ran the native binary against a repository containing a breaking finding and checked that the process exited with code 1. Because the CLI returned the expected exit code, the test passed even though its JSON report had lost the fields the Action relied on.
What should a native CLI release test verify?
The author’s corrective approach was to test the report produced by the actual native artifact on each platform’s runner, rather than treating a successful process exit as proof of correct output.
- Run the built native executable against a fixture that is expected to contain a breaking finding.
- Parse its JSON output and assert that the expected finding fields are present, including a
severityvalue ofbreaking. - Check both the process exit status and the report content; neither check substitutes for the other.
- Make the Action reject findings that lack severity instead of allowing malformed data to look like a clean scan.
- Include cases with multiple locations so serialization of the
Evidence[]type is exercised as well.
This is the lesson of one reported incident, not evidence of how often native-image serialization defects occur. The account appeared in a DEV Community search result accessed October 7, 2026; the article page itself could not be fetched for direct verification. Its release claims, including that the fix is in v0.3.0 and later and that the v0 tag points to the fixed release, are therefore attributed to the author rather than independently confirmed.
Quick Recap
Rank #4
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
