[BUG] Transformer errors saves invalid transformed message

[mgaffigan]

Describe the bug
An error during a transformer results in invalid data in the "transformed" message.

To Reproduce
Add channel mapping XML to JSON. Set source outbound message template to {}. Add throw Error('Always'); as transformer.

Expected behavior
Transformed message should be {}

Actual behavior
Transformed message is the original xml.

[tonygermano]

This is intended behavior. At the start of the transformer the transformed content is set to the serialized raw content based on the inbound data type. It's then updated at the end of the transformer assuming it produced a result.

This is more apparent if reproducing with an inbound type of something like hl7 or delimited, resulting in the initial transformed content being set to the xml version of the raw content.

[mgaffigan]

It may be known behavior, but I don't see how it comports with the design that the transform template can have a different type than the received message, or that "steps" exist in any meaningful way beyond the UI.

Principle of least surprise would argue this is a bug, but I'll equally argue for changing the behavior if it is called a feature request.

[tonygermano]

It is intended and known behavior. It matches the (serialized) inbound type at the start of the transformer and is updated to the (pre-serialized) outbound type after successful completion.

I would likely be opposed to it as a feature request. It's a development tool, which does not get saved to the database when a channel is in production mode. If the transformer fails to complete, it's far more useful to see what the transformed msg looked like at the start of the transformer than what (static) tmp looked like at the start of the transformer.

Transformer steps mainly exist because they can have different types and support the drag-and-drop builders, though they can be helpful for breaking up large javascript steps, as well. They don't have any meaning once the channel's javascript has been compiled for deployment.

[mgaffigan]

The output of the transformer (when the transformer template is set) is tmp, not msg. The point of tmp is to modify and translate.

For connectors without transformer templates, I agree that showing the state of msg is reasonable (since that would have been the result of transformation assuming success). If a transformer template is set, any modifications to msg are impotent.

Whether you intend steps to be used only for mappers is irrelevant to their usability generally. The current runtime embodiment is confusing to anyone not yet cut by Mirth's sharp edges.

Growth comes from reducing friction to adoption.

[tonygermano]

It doesn't show any modifications while it is in progress. It has an initial state, which is shown if the transformer fails, and a final state if it completes successfully.

[mgaffigan]

Yep. That's what I'm saying is a defect in implementation.

[tonygermano]

I disagree that it is a defect. It's very useful to see what the transformed inbound message looks like when something fails, so you can see the data that caused the error, and it's still "transformed" content.

Again, I think the usefulness of the current approach is much more apparent when you are using data types where the transformed content doesn't look the same as the raw or encoded content. In an HL7->HL7 transformer, the transformed content is always xml. If you are using a binary inbound data type (DICOM, for example,) how would you ever see what the transformed msg looked like if something was failing?

People who want "in-progress" updates of a transformer usually either generate log messages or place information they care about in one of the java maps. I don't think that's wrong, and it's probably a lot more useful than showing whatever happened to be assigned to tmp at the time, assuming it could be serialized at the time of failure.