[pacmano1]

Closes #572.

When an alert fires, its actions go out first. Then AlertWorker.ActionTask builds the "Alert Dispatched" event by calling toString() on every value in the alert's context. A null value throws, and the task runs on an executor whose Future nobody reads, so the event is never written and nothing is logged.

It's not only the server name. A source transformer that throws, or a call to alerts.sendAlert(...), leaves connectorType null, and those alerts never wrote the event either, server name or not. Measured below.

The blank server name case is courtesy of #259, which put serverName in the context. Tony spotted the null in review, wrote a nice paragraph about it, and it still collected three approvals, with #47 lined up to fill it in. #47 is still lined up. In fairness, the toString() loop that actually throws has been sitting there since Mirth.

Change

• A null context value becomes an empty attribute, Objects.toString(value, ""). AuthorizationController does the same for audit events, and empty is also what the feat: add serverName variable on alert template #259 thread wanted for the template variable.
• The event step gets the same try/catch and logger.error the protocol and email steps in that method already have, so if it breaks again it says so.
• Alert templates are untouched. With no server name set, ${serverName} still renders as the literal token, as discussed in feat: add serverName variable on alert template #259, and so does ${connectorType} on transformer and alerts.sendAlert alerts. Checked on an engine built from this branch.
• Heads-up for upgrades: alerts on transformer errors or alerts.sendAlert, and any alert on a server with no name, will start writing an "Alert Dispatched" event per action. They never did before. Each one carries the full error text in error and errorMessage, same as the events that were already being written.

AlertWorkerTest covers a null server name and connector type, a set server name, and a failing dispatch getting logged. The first and the last fail on main.

How to verify

Fresh engine on Derby, no server name set (Settings, Server, Server Name empty).

1. Create a channel "Receiver": Channel Reader source, any destination.
2. Create a channel "Throws": Channel Reader source, JavaScript Writer destination with throw new Error('boom');.
3. Create a channel "Transformer Throws": Channel Reader source with a JavaScript transformer step throw new Error('transformer boom');, any destination.
4. Create an alert on any error for "Throws" and "Transformer Throws", with a Channel action to "Receiver". Enable it and deploy all three channels.
5. Send a message to "Throws".
6. Set a Server Name and save. Send a message to "Transformer Throws".
7. Look in Events for "Alert Dispatched".

Before: "Receiver" gets both alert messages, but neither "Alert Dispatched" event is written, and mirth.log says nothing about it. After: both events are there, with serverName blank on the first and connectorType blank on the second.

Tested

./gradlew clean build -x signSetupJars: 913 tests, 0 failures, 0 skipped.

Live on Derby, one engine built from main (cd802ef) and one from this branch, one message per row:

Scenario	Alert action delivered (main / this PR)	Alert Dispatched event (main / this PR)
No server name, JavaScript Writer throws	yes / yes	missing / written, serverName blank
Server name set, JavaScript Writer throws (control)	yes / yes	written / written
Server name set, source transformer throws	yes / yes	missing / written, connectorType blank
Server name set, alerts.sendAlert(...)	yes / yes	missing / written, connectorType blank

On main, mirth.log has nothing about the three missing events. On this branch the new error line never shows up, since nothing failed.

Release Note

The "Alert Dispatched" event is no longer skipped when an alert value is missing

When an alert fired, its actions went out, but the "Alert Dispatched" event wasn't written if one of the alert's values was missing, and nothing was logged. That happened for any error alert while Settings, Server, Server Name was blank, and for alerts on source transformer errors or alerts.sendAlert(...), which carry no connector type. The event is now written with those values as empty attributes, and a failure to write it is logged. (#572, #573)

After upgrading, installs with such alerts will see "Alert Dispatched" events they didn't get before. Alert templates are unchanged: with no server name set, ${serverName} still renders as the literal ${serverName}.

Co-authored with Claude Code.

[github-actions]

Test Results

  143 files  +1    143 suites  +1   4m 2s ⏱️ +48s
  940 tests +3    940 ✅ +3  0 💤 ±0  0 ❌ ±0 
1 102 runs  +3  1 096 ✅ +3  6 💤 ±0  0 ❌ ±0 

Results for commit 7f9ca4f. ± Comparison against base commit cd802ef.

♻️ This comment has been updated with latest results.

[tonygermano]

@pacmano1 I already approved, but can you add a release note section to the bottom of the PR description?

[pacmano1]

Added.

[jonbartels]

Logging improvement. I hate to reject the PR for it but a clear log will help a lot in the event that this does throw.

A question or nit - The "How to verify" section describes a channel setup that would validate the issue. Should this be a smoke test channel? I am leaning "no" since the unit test seems sufficient

[jonbartels]

Will this exception include useful information to know:

• what alert failed?
• why it failed?

Eg should this say something like "Error dispatching the alert dispatched event for serverID xxxxx for event zzzz"

[tonygermano]

I'm not sure if this is necessary. The logging framework already knows which server produced the log entry.

Alerts have an id, but I don't know if that is in any way useful. There is not an event to reference because that is the thing that failed.

[tonygermano]

"Alert Dispatched" is the event type. See line 212 in this file.

[pacmano1]

Added the alert's name and id: Error dispatching the Alert Dispatched event for alert "<name>" (<id>). Forced the dispatch to fail on a running engine to check it: mirth.log shows that line, then the exception and its stack trace. On the smoke test question, agreed, no.

Co-authored with Claude Code.

[pacmano1]

@jonbartels I agree. Especially as the dude always complaining about the use of logger.* throwing stuff to the console leaving me asking "where did that come from and why didn't some prepend the channelName and maybe location in the channel?".