bamaer commented on PR #9149:
URL: https://github.com/apache/hop/pull/9149#issuecomment-6515708348
Docs only, so nothing here can break anything. I checked the new Result
sections against the action code on main. They hold up, apart from one case.
**Fix before merge**
- **Nr errors less than is also true when the action fails before it starts
transferring.** That failure counts as 1 error, and 1 is "at most *Limit
files*" (default 10). On a closed port (127.0.0.1:1, connection refused), Get a
file with FTP and FTP delete both finish with `result=[true]` under *Nr errors
less than*. Under the default *All works fine*, Get a file with FTP finishes
with `result=[false]`.
- `ftp.adoc`, False row: an unreachable server, a refused login and an
invalid wildcard all give true under this condition. A missing remote directory
and the move-to folder checks still give false, whatever the condition.
- `ftpdelete.adoc`, False row: every case listed gives true under this
condition (unreachable server, missing remote directory, empty wildcard). The
True row already says this for the empty wildcard.
Suggested fix: add to both False rows: "With *Nr errors less than*, these
failures count as 1 error, so the action is true when *Limit files* is 1 or
more." A refused connection counting as success looks like a bug, so it could
also go on the "Found while testing" list.
What I checked: I read `ActionFtp`, `ActionFtpDelete`, `ActionFtpPut`,
`ActionSftpPut` and `ActionHttp` on main against each row, and checked the
renamed labels against the `en_US` bundles. I ran the closed-port case with
hop-run on a local 2.21.0-SNAPSHOT client. I did not rerun the FTP, SFTP and
HTTP server tests from the description.
--
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]
