[manerow]

Fixes #37266

Problem

The helpers API (GET /v1/notificationTemplates/helpers) returns an example for each notification template helper. Most of them used names a template doesn't have, such as status and fieldName, or fields that don't exist, such as entity.oldDescription. Copied into a template, 17 of the 26 examples rendered nothing. The Collate template editor is starting to show these examples to users (open-metadata/openmetadata-collate#8309).

What this PR changes

• Each example now reads data a template really has. For example, hasFieldInChanges is shown inside the groupEventChanges block it needs, and resolveDomain loops over entity.domains.
• A new test renders every example from every helper against a realistic event and fails if any comes out empty, so a new helper can't ship with an example that does nothing. The math and filter examples print literal text around the helper, so they also have exact-output tests.
• It includes the same one-line buildEntityUrl example fix as Fixes #37191: Use the two-argument buildEntityUrl example #37194, because the new test covers that helper too. The two identical changes merge cleanly in either order.

No helper behaviour changes, only the example text the API returns.

How it was tested

• HandlebarsHelperExampleTest, NotificationTemplateHelperCoreTest, NotificationTemplateHelperAdvancedTest, BuildEntityUrlHelperTest and SystemTemplateParityTest: 77 tests, all passing. On the old examples, 17 of the 26 cases in the new test fail.
• In the browser, on a local stack with Fixes #37191: Use the two-argument buildEntityUrl example #37194 and this change, typing {{ in the Collate template editor shows the new examples.

[gitar-bot]

Code Review ✅ Approved 1 closed / 1 findings

🟢 Low risk · The PR updates helper example text and adds rendering tests; helper execution behavior is unchanged, limiting impact to examples shown to users.

Makes every notification template helper example render against a realistic event by reading data templates actually have, such as entity.domains and the groupEventChanges block, and adds a test that fails if any example renders empty. The non-blank check previously passed on literal text even when the helper rendered nothing, and that gap is resolved. No open issues found.

✅ 1 closed

✅ Quality: Non-blank check passes on literal text even when the helper renders nothing

📄 openmetadata-service/src/test/java/org/openmetadata/service/alerting/content/template/handlebars/helpers/HandlebarsHelperExampleTest.java:58-64 📄 openmetadata-service/src/main/java/org/openmetadata/service/alerting/content/template/handlebars/helpers/MathHelper.java:101-102 📄 openmetadata-service/src/main/java/org/openmetadata/service/alerting/content/template/handlebars/helpers/FilterHelper.java:86
exampleRendersOutput only asserts !rendered.isBlank(). Several of the new examples put literal text or other fields next to the helper call, so they pass even when the helper produces nothing. The new math example {{#each entity.owners}}{{math @index '+' 1}}. {{name}} {{/each}} still renders . alice . bob if math returns empty or the wrong number (MathHelper also swallows exceptions and returns 0). In the filter example, {{length tags}} classification tags passes whether or not filter removed anything. So the test does not catch what it is meant to catch: an example whose helper renders nothing. A simple fix is to give each test case an expected output, or at least an expected substring, for the fixture event, and assert on that.

Verification

Rules No rules evaluated

Functional validation Not enabled

Set up

Auto-approval Not enabled

Set up

_{For more verification details, comment gitar display:verbose.}

Options

Display: compact → Showing compact verification results.

Comment with these commands to change the behavior for this request:

Compact

gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Powered by Gitar — free for open source}