Issue #8000 : Route unreadable XML files to error handling

[vbhanuchander-lang]

Addresses #8000.

The "Get data from XML" transform aborts the pipeline when a file cannot be parsed, instead of
routing the failure to the transform connected to its error hop. Reading the same document from a
field, or reading the file name from a field, behaves correctly — which is what makes the file path
look like an oversight rather than a design choice.

Cause

openNextFile() catches the parse failure and then unconditionally does this:

logError(...);
stopAll();
setErrors(1);
return false;

It never asks whether the transform has error handling configured, so stopAll() takes the whole
pipeline down. That produces the "Pipeline is killing the other transforms!" line in the report. The
in-fields path does ask — processPutRow checks getTransformMeta().isDoingErrorHandling() and
calls putError — which is exactly why the two paths behave differently.

Change

When error handling is enabled, the file is sent to the error stream and reading continues with the
next file. When it is not, the previous behaviour is untouched.

One wrinkle worth flagging for review. data.filenr is normally incremented before the document is
parsed, so recursing into openNextFile() moves on to the next file. But a failure raised earlier
— resolving the file, reading its size, its attributes — leaves the pointer untouched, and recursing
would retry the same file forever. The change records the pointer on entry and steps over the file
explicitly if it has not advanced.

openNextFile() now declares HopTransformException, because putError throws it. Every caller
already propagates HopException, so this does not ripple.

Tests

testErrorHandlingContinuesOnBadXmlFile is the file-based counterpart to the existing
testErrorHandlingContinuesOnBadXml: a temporary folder holding a good file, an unparseable one and
another good file, with an error hop attached.

• both readable files are still read — 2 rows from the first, 1 from the third
• the unreadable file yields exactly one error row
• the pipeline reports no errors

Reverting the production change fails that test with transform should not report errors ==> expected: <0> but was: <1>, which is the behaviour described in the issue.

Verification

• mvn -pl plugins/transforms/xml -Pskip-uitest test — 154 tests, 0 failures, 0 errors
• mvn spotless:check and mvn apache-rat:check pass on the module

---

• I hereby declare this contribution to be licensed under the Apache License Version 2.0, January 2004