minhpham1810 opened a new pull request, #3280: URL: https://github.com/apache/sedona/pull/3280
## Did you read the Contributor Guide? - [x] Yes, I have read the [Contributor Rules](https://sedona.apache.org/latest/community/rule/) and [Contributor Development Guide](https://sedona.apache.org/latest/community/develop/) ## Is this PR related to a ticket? - [x] Yes, and the PR name follows the format `[GH-XXX] my subject`. Closes #3276 ## What changes were proposed in this PR? `ST_ApproximateMedialAxis` and `ST_StraightSkeleton` could flood executor logs: the `campskeleton` library (`org.datasyslab:campskeleton`, an external jar not vendored in this repo) catches its own internal `java.lang.Error: Planes do not intersect at a single point.` — raised for degenerate collision events, typically from polygons with many short, near-collinear edges — and prints the full stack trace to `System.err` instead of failing. A single 557-vertex polygon could print this trace 130-190 times per call, and a batch job skeletonizing a few thousand polygons produced 100k+ traces in a single run, burying real errors. Since the library itself isn't vendored here, this PR suppresses the flooding from the Sedona side (`StraightSkeleton.computeSkeleton`): before invoking the library, it installs a process-wide, line-buffering filter on `System.err` that recognizes and silently drops exactly this known-harmless stack trace (logging one DEBUG-level line per occurrence instead) while passing every other line through unchanged. The filter re-validates on every call via a cheap reference check, so it self-heals if something else replaces `System.err`, and it avoids holding any lock around the actual (expensive, parallelizable) skeleton computation. ## How was this patch tested? Added `StraightSkeletonTest#testDegenerateCollinearPolygonDoesNotFloodStderr`, which runs the 557-vertex repro polygon from the issue, captures `System.err` during the call, and asserts none of campskeleton's degenerate-collision trace lines leak through, while the skeleton output is still produced correctly. Ran the full `StraightSkeletonTest` (24/24) and `FunctionsTest` / `raster.FunctionsTest` suites (327/327) locally — all pass. Also verified with a standalone harness against the issue's exact repro polygon: before the fix, ~71KB / 130+ suppressed-trace occurrences leaked to stderr; after the fix, 0 bytes leak, with identical skeleton output (1087 edges either way). ## Did this PR include necessary documentation updates? - [x] No, this PR does not affect any public API so no need to change the documentation. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
