sangkyoonnam opened a new issue, #1289: URL: https://github.com/apache/flink-agents/issues/1289
### Search before asking - [x] I searched in the [issues](https://github.com/apache/flink-agents/issues) and found nothing similar. ### Description An interrupt while tree-sitter writes its native library for the first time leaves `TSParser` unusable for every later parse in the same class loader. This is now breaking `ut-java` CI: `BashToolTest` reports 1 failure and 7 errors across 8 tests, followed by 15 errors across 16 tests in `BashValidatorTest`. As of 2026-10-20 05:12 UTC, 14 of the 19 completed CI runs created since 2026-10-19 17:40 UTC, excluding `release-0.3` branches, had at least one failing `ut-java` job, including all three runs on main. The three whose logs I opened fail this way: [39297180793](https://github.com/apache/flink-agents/actions/runs/39297180793) (JDK 11), [39345725996](https://github.com/apache/flink-agents/actions/runs/39345725996) (JDK 21) and [39352352652](https://github.com/apache/flink-agents/actions/runs/39352352652) (JDK 17, main `b17dc142`). `interruptionPropagatesInsteadOfReturningToolResult` interrupts the test thread and then calls `BashTool`. If no earlier test in that JVM has created a `TSParser`, this call loads tree-sitter's native library. When `~/.tree-sitter/lib` has no matching copy, tree-sitter 0.25.3 acquires a lock with `FileChannel.lock()` before writing the library, and acquiring that lock throws on an interrupted thread. `TSParser`'s static initializer fails, and later uses of `TSParser` fail with it. From the JDK 11 job: ``` Caused by: java.lang.ExceptionInInitializerError at org.apache.flink.agents.plan.tools.bash.BashValidator.parser(BashValidator.java:99) Caused by: java.lang.RuntimeException: java.nio.channels.FileLockInterruptionException at org.treesitter.utils.NativeUtils.loadLib(NativeUtils.java:148) at org.treesitter.TSParser.<clinit>(TSParser.java:27) Caused by: java.nio.channels.FileLockInterruptionException at java.base/sun.nio.ch.FileChannelImpl.lock(FileChannelImpl.java:1138) at org.treesitter.utils.NativeUtils.loadLib(NativeUtils.java:138) ``` The CI workflow doesn't cache `~/.tree-sitter`. In five Ubuntu `ut-java` jobs I compared, both failures ran `BashToolTest` before `BashValidatorTest` on image `ubuntu24/20261018.339`, and all three passing jobs, including main `a50a8a18`, ran them in the opposite order on `ubuntu24/20261012.334`. One CI run used both images. I haven't established whether the image affects test order. On JDK 11 and 17, parallel Java tool calls run on `AsyncBatchExecutor` workers, which it interrupts when the batch driver aborts or the executor shuts down. In a TaskManager, an interrupt during the first uncached library load would leave `TSParser` unusable and make later bash calls that need parsing fail in the same class loader. I haven't reproduced this through a job. I'd fix it in `BashValidator`: create the first `TSParser` on its own thread, wait for it without giving up on an interrupt, and restore the caller's interrupt flag afterward. `BashTool` still sees the interrupt in `waitFor` and throws `CancellationException`, as the test expects. Clearing the flag around the load isn't enough, because an interrupt can also arrive while the library is being written. Each regression test starts a fresh child JVM with `-Dtree-sitter-lib` pointing to an empty directory. Both callers start interrupted, and the second also receives repeated interrupts until it exits. Both tests then validate again from the main thread. To unblock CI first, I'm opening a hotfix PR that creates the parser in that test before it interrupts the thread. Could you assign this issue to me for the `BashValidator` fix? ### How to reproduce On main (`88fab2b3`), point tree-sitter at an empty directory so it has to write the library: ``` mvn -pl plan -am install -DskipTests JDK_JAVA_OPTIONS="-Dtree-sitter-lib=$(mktemp -d)" mvn -o -pl plan surefire:test -Dtest=BashToolTest ``` This gives `Tests run: 8, Failures: 1, Errors: 7` with the same exception chain. `-Dtest=BashToolTest#allowedSimpleCommandRuns` with an empty directory passes. Without the `JDK_JAVA_OPTIONS` override, all 8 tests pass when `~/.tree-sitter/lib` already contains a matching library. With the change above, `BashToolTest` and `BashValidatorTest` pass with an empty directory on JDK 11, 17 and 21. Both child-JVM tests fail 3/3 on main. With a version that only clears the flag around the load, the first passes and the second still fails 3/3. With the change, both pass 10/10. ### Version and environment main `88fab2b3`, tree-sitter 0.25.3. Reproduced on macOS arm64 with JDK 17. ### Are you willing to submit a PR? - [ ] I'm willing to submit a PR! -- 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]
