Skip to content

Fix #309: make channelName available in Postprocessor script - #395

Merged
tonygermano merged 2 commits into
OpenIntegrationEngine:mainfrom
ggiannola:fix/309-postprocessor-channelname
Jul 31, 2026
Merged

Fix #309: make channelName available in Postprocessor script#395
tonygermano merged 2 commits into
OpenIntegrationEngine:mainfrom
ggiannola:fix/309-postprocessor-channelname

Conversation

@ggiannola

@ggiannola ggiannola commented Jul 29, 2026

Copy link
Copy Markdown
Contributor

Summary

Fixes #309. The channelName variable was not available in Postprocessor scripts, even though it is available in Deploy, Undeploy, and Preprocessor scripts.

Root cause

The Postprocessor scope (JavaScriptScopeUtil.getPostprocessorScope) derives channelName from message.getMergedConnectorMessage().getChannelName().

However, Message.getMergedConnectorMessage() built the merged ConnectorMessage setting channelId, messageId, serverId, and receivedDate — but never channelName. The value therefore resolved to null in Postprocessor scripts.

This also explains why the other script contexts were unaffected: they receive the channel name directly (Deploy/Undeploy via getDeployScope/getUndeployScope, Preprocessor from the connector message) rather than through the merged connector message.

Fix

In Message.getMergedConnectorMessage(), populate channelName on the merged connector message:

  • from the Message's own channelName field, and
  • falling back to the source connector message's channelName, which is reliably set during processing (see the ConnectorMessage construction in Channel).

The fallback matters because the Message created during processing does not always carry channelName, while the source connector message does.

Tests

Added MessageTest covering three cases:

  1. The merged message inherits channelName from the source connector message.
  2. The merged message uses the Message-level channelName when set.
  3. channelName stays null when unavailable, so the fix does not fabricate a value.

Verified with ./gradlew :donkey:test: 21 tests pass, 0 failures (MessageTest 3, StatisticsTest 9, JdbcDaoTest 8, ChannelTest 1).

@ggiannola
ggiannola marked this pull request as ready for review July 29, 2026 18:09
@ggiannola
ggiannola force-pushed the fix/309-postprocessor-channelname branch from cfe7bcb to 0de1890 Compare July 29, 2026 18:14
@pacmano1

pacmano1 commented Jul 29, 2026

Copy link
Copy Markdown
Contributor

@ggiannola, this works in the post processor.

logger.info(ChannelUtil.getChannelName(channelId))

Not that your PR is "wrong", but based on this trivial workaround it seems unnecessary.

@jonbartels jonbartels left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approved.

I have a non-blocking comment - Are there other fields missing from the post-processor?

You found that channelName was missing. Are there other common fields from other scripts that are missing that could also be added in this PR?

@ggiannola

ggiannola commented Jul 30, 2026

Copy link
Copy Markdown
Contributor Author

@ggiannola, this works in the post processor.

logger.info(ChannelUtil.getChannelName(channelId))

Not that your PR is "wrong", but based on this trivial workaround it seems unnecessary.

Thanks @pacmano1 agreed.

Worth noting the postprocessor scope already tries to supply channelName; it was wired in deliberately back in 2015 (2fd0148, MIRTH-1763) and has silently been null ever since because Message.getMergedConnectorMessage() never populated the field. So this is a latent bug rather than a new feature.

It's also broader than the variable, message.getMergedConnectorMessage().getChannelName() is public userutil API and returns null in every postprocessor, which ChannelUtil doesn't address.

4 lines, no API change. But if you'd rather leave it, happy to close.

@github-actions

github-actions Bot commented Jul 30, 2026

Copy link
Copy Markdown

Test Results

658 tests  +3   658 ✅ +3   2m 14s ⏱️ + 1m 0s
110 suites +1     0 💤 ±0 
110 files   +1     0 ❌ ±0 

Results for commit c556c59. ± Comparison against base commit 776690e.

♻️ This comment has been updated with latest results.

@pacmano1

Copy link
Copy Markdown
Contributor

@ggiannola , I'll defer to the other maintainers. I am wishy washy on it, lol.

@tonygermano tonygermano left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me. Thanks for the fix and added tests!

…essor script

The Postprocessor scope derives channelName from
message.getMergedConnectorMessage().getChannelName(), but
Message.getMergedConnectorMessage() never populated channelName on the
merged ConnectorMessage. As a result the channelName variable was null
in Postprocessor scripts, even though it is available in Deploy,
Undeploy, and Preprocessor scripts.

Populate channelName on the merged connector message from the Message's
own channelName, falling back to the source connector message's
channelName (which is reliably set during processing).

Adds MessageTest covering the three cases.

Signed-off-by: Giovanni Giannola <giogiannola@globalesm.com>
New files in this project use SPDX headers attributing copyright to the
contributor, rather than the legacy Mirth Corporation header carried by
pre-fork files.

Signed-off-by: Giovanni Giannola <giogiannola@globalesm.com>
@tonygermano
tonygermano force-pushed the fix/309-postprocessor-channelname branch from 0de1890 to c556c59 Compare July 31, 2026 16:10
@tonygermano tonygermano modified the milestone: Next Release Jul 31, 2026
@tonygermano
tonygermano merged commit ac3a398 into OpenIntegrationEngine:main Jul 31, 2026
6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[BUG] channelName variable is not available in Postprocessor script

6 participants