Adalennis opened a new issue, #9220:
URL: https://github.com/apache/hop/issues/9220
### Apache Hop version?
SNAPSHOT-20261021
### Java version?
Java 21
### Operating system
macOS
### What happened?
Found while documenting the result of these actions (#8970, PR #9217).
Points 1 to 3 were tested with hop-run (MongoDB 7 in Docker); points 4 and 5
come from reading the code, as there was no Snowflake account or Databricks
workspace to test with. Line numbers are from today's main.
**1. Build documentation never sets its own result**
ActionDoc.execute() passes the previous result to
DocBuilder.buildDocumentation() and returns it (ActionDoc.java lines 142-143).
DocBuilder only sets false on an error (DocBuilder.java line 249), never true.
So after a false action on an unconditional or a failure hop, Build
documentation writes the whole documentation and is still false, and the
failure hop is followed. The same kind of issue was fixed for Repeat in #9132.
Expected: the action sets true when the documentation is written.
**2. MongoDB QL runs only the first of several comma-separated instructions**
The action page said that several instructions can be separated by commas.
Only text starting with `[` is read as a list (ActionMql.java line 171);
anything else goes through Document.parse() (line 180), which reads the first
JSON document and ignores the rest. `{"insert": "c", "documents": [{"v":
"a"}]},{"insert": "c", "documents": [{"v": "b"}]}` is true but only inserts "a".
Expected: an error for text after the first document (or treat
comma-separated documents as a list). The docs now say to use a JSON array.
**3. MongoDB QL is true when MongoDB reports write errors**
db.runCommand() (lines 176 and 180) only throws when the command itself
fails. Write errors come back in the reply (`writeErrors`, `writeConcernError`)
with `ok: 1`, and the action doesn't look at them. An insert of two documents
with the same `_id` is true with 0 errors, although the second document is not
inserted.
Expected: the action fails when the reply holds writeErrors or a
writeConcernError.
**4. Snowflake warehouse manager: false with 0 errors, and Create/Alter
don't resolve the warehouse name (from the code)**
execute() sets `result.setResult(false)` on an error (WarehouseManager.java
line 346) and after a failing validate(), but never sets the number of errors,
so a failing action reports 0 errors. Also getCreateSQL() and getAlterSQL()
append `warehouseName` as it is (lines 392 and 435), while the Drop, Resume and
Suspend statements use `resolve(warehouseName)` (lines 358, 368, 378):
`${WAREHOUSE}` works for Drop, Resume and Suspend but not for Create and Alter.
Expected: 1 error when the action fails, and the warehouse name resolved for
every action.
**5. Databricks job wait: "Cancel Databricks run if workflow is stopped"
also cancels on a timeout (from the code)**
DatabricksRunWaiter.waitFor() calls tryCancel() when the workflow is stopped
(line 67), but also when the timeout is reached (lines 90-93), with the same
flag. A run that takes longer than the timeout is canceled on Databricks,
although the option only mentions a stopped workflow. Also, for a run that ends
CANCELED the action logs the error but doesn't fill the error result variable
(ActionDatabricksJobWait.java line 184), while it does for every other failure
(line 199).
Expected: a timeout only stops waiting (or a separate option to cancel on
timeout), and the error variable is set for a canceled run too.
The current behaviour is documented on the action pages (PR #9217), so the
docs need an update when these are fixed.
### Issue Priority
Priority: 3
### Issue Component
Component: Hop Gui
--
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]
