Adalennis opened a new issue, #9175: URL: https://github.com/apache/hop/issues/9175
### Apache Hop version? SNAPSHOT-20261021 ### Java version? Java 21 ### Operating system macOS ### What happened? Found while documenting the result of these actions (#8970, second batch, PR #9024). Reproduced with hop-run; the current behaviour is documented in a NOTE or in the Result table of each action page, so the docs need an update when these are fixed. **1. Move files: "Nr errors lesser than" is true when the number of errors equals the limit** `updateErrors()` stops the action when `nrErrors >= limitFiles` (line 1080), but `getSuccessStatus()` returns true when `nrErrors <= limitFiles` (line 396). With *Nr errors lesser than* 1 and the last entry failing (a source folder that doesn't exist), the action is true with 1 error. When an earlier entry reaches the limit, the action stops and is false. The same `<=` is in Get a file with FTP and FTP delete (#9170). **2. Move files: with If destination file exists = Fail, one existing file counts as two errors** With one file already in the destination, the log says "Success condition was broken. We have 1 error(s)", but the action ends with 2 errors. This happens with a single file as source and with a folder as source. With *Nr errors lesser than*, the limit is reached twice as fast. **3. Delete files: an invalid regular expression deletes nothing, and the action is true** `getFileWildcard()` (line 324) compiles the wildcard inside the file selector, where the `PatternSyntaxException` is swallowed. With a wildcard like `[`, no file is deleted and the action is true with 0 errors. **4. Delete files: a result row with fewer than two fields stops the action, which stays true** With *Copy previous results to args*, `populateDataForWorkflowExecution()` returns at the first row with fewer than two fields (lines 158–164). That row and the rows after it are not processed, only an error is logged, and the action is true with 0 errors. **5. Zip file: with Get arguments from previous, the action never sets its result** When every row is zipped, the `fromPrevious` branch of `execute()` (lines 917–961) never calls `result.setResult(true)`, so the previous action's result is passed on. After a failure hop (for example a File exists that is false), the action is false with 0 errors although the zip was created and is in the result files. Likewise, an empty *Source directory/file* logs "Source folder/file is empty! Ignoring row..." as an error (line 992) but passes on the previous result instead of being false. **6. Zip file: a source file that can't be moved after zipping leaves the action true** With *After zipping* set to *Move files*, `moveFile()` returns false when the move fails, but `successResult = true` (line 560) overwrites it. The action is true with 0 errors and the zip is in the result files; only the log shows the failed move. A failed *Delete files* makes the action false. ### Issue Priority Priority: 3 ### Issue Component Component: Actions -- 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]
