Croway opened a new pull request, #29333: URL: https://github.com/apache/camel/pull/29333
JIRA: [CAMEL-26066](https://issues.apache.org/jira/browse/CAMEL-26066), reopened because `ScpFileNameControlCharTest.testFileNameWithOtherControlCharIsWritten` fails on the Jenkins builds of `main` (`expected: <Hello World> but was: <>`, on s390x, ppc64le and ubuntu-avx, each with a different parameter). ### What was wrong The cause is not the file name check of #29285: it is in how the scp producer reads the acknowledgements of the remote scp. - The remote scp (`scp -t`) sends a first acknowledgement as soon as it starts, before it reads the first protocol line (OpenSSH `scp.c` `sink()`, Apache MINA SSHD `ScpHelper.receive`). - JSch drops what a channel receives before its input stream is taken (`Channel.write` ignores the data while no stream is set). The producer took the streams in `write()`, after `channel.connect()`. - So it depended on timing: - when that first acknowledgement arrived before the streams were taken, it was dropped and the reads happened to match; - when it arrived later, as on a slow machine, the producer read it as the answer to the file header, and every later read was one step behind. - When the reads were one step behind: - the producer read the acknowledgement that the server sends once it has created the file as the final one, and completed the exchange before the server had written the data. The new test read the file at that point and found it empty; - an error that the server reports for the file, for example when it cannot write it, was not seen, and the exchange succeeded. ### What changed `storeFile` now uses `connectAndWrite`, which takes the channel streams before it connects and reads that first acknowledgement before it sends the first protocol line. Then each acknowledgement read is the answer to the line or data just sent, and the last one comes once the server has written the file. This is the order of the JSch `ScpTo` example. `storeFileDirectly` (used for `checksumFileAlgorithm`) is left as it is: #29317 (CAMEL-26672) fixes it, and it can use `connectAndWrite` too. ### Tests New `ScpProduceAcknowledgementTest`, against the embedded MINA SSHD server. Each case runs with a normal server and with one that starts the scp command 500 ms after the exec request, so that the first acknowledgement arrives after the channel is connected: - the file, and a nested file, are complete on the server when the exchange completes; - a file that the server cannot write, or cannot create, fails the exchange with the server's message. On `main`, the slow-server case of "cannot write" fails the same way in each run: `Expected org.apache.camel.CamelExecutionException to be thrown, but nothing was thrown`. With the fix, all 8 pass. The `camel-jsch` suite passes (40 tests, 3 skipped as before), and `ScpFileNameControlCharTest` plus the new test passed 10 runs in a row. ### Docs and upgrade guide No option or default changes. A producer that used to complete before the server had written the file now waits for it, and an error that the server reports for the file now fails the exchange. ### Backport Straight cherry-picks to `camel-4.22.x` and `camel-4.18.x` follow: the send code is the same there, and both branches have `ScpFileNameControlCharTest` from the #29285 backports. _Claude Code on behalf of Federico Mariani_ -- 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]
