Skip to content

Conversation

@sbliven
Copy link
Member

@sbliven sbliven commented Oct 13, 2025

Description

Following #2271, this adds a ignoreErrors configuration option to the email action for cases where you don't want an error sending the email to block the job POST or PATCH request.

It also makes other small improvements and bug fixes regarding emails.

Motivation

Generating the email can cause errors, either from templating or from sending the URL itself. This allows jobs to continue despite the error. Errors are logged in all cases.

Fixes

  • improve error message in the switch regex case
  • fix a bug where job properties were not available to templates in some cases

Changes:

  • allow email actions to ignore errors from remote calls
  • add an example job config for sending emails only for finished jobs
  • add 'matches' and 'default' handlebars helpers

Tests included

  • Included for each change/fix?
  • Passing?

Documentation

  • swagger documentation updated (required for API changes)
  • official documentation updated

official documentation info

@sbliven sbliven marked this pull request as ready for review October 16, 2025 15:48
@sbliven sbliven requested a review from a team as a code owner October 16, 2025 15:48
@sbliven sbliven changed the title feat: allow email actions to ignore errors feat: email actions improvements Oct 16, 2025
auth: "#jobOwnerUser"
actions: []
actions:
- # Only send emails for updates to status 'finished*'
Copy link
Member Author

Choose a reason for hiding this comment

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

Should this be added to jobConfig.recommended.yaml as well, since sending email is such a common task?

jobParams: true,
contactEmail: true,
},
allowProtoPropertiesByDefault: false, // limit accessible fields for security
Copy link
Member Author

Choose a reason for hiding this comment

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

There were two possible solutions to the problem of template variable coming from mongo (JobClass, DatasetClass, etc). The previous solution was whitelisting properties which we wanted to support. This wasn't maintained (now they are nested under job) so this broke. Instead we call toObject on mongo classes before adding them to the template context.

Another solution would have been to just allow all ProtoProperties here, and then we wouldn't need the overhead of toObject (at least for handlebars). I didn't feel confident about the security ramifications of that, and we might still need toObject for JSONPath calls (which also fail on ProtoProperties).

@sbliven
Copy link
Member Author

sbliven commented Oct 16, 2025

This is ready to review. I am still working on a new job-template.html file, but it will come in a fresh PR.

Copy link
Member

@minottic minottic left a comment

Choose a reason for hiding this comment

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

LGTM, thanks! some minor comments for eventual later PRs

Copy link
Member

Choose a reason for hiding this comment

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

would it make sense to test some of the handlers here?

Copy link
Member Author

Choose a reason for hiding this comment

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

Which handlers do you mean?

Copy link
Member

Choose a reason for hiding this comment

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

I meant to have a template that has some handlers inside, e.g. "eq" ro "regex" or similar and test that the email is rendered correctly. But this could indeed be part of a later PR, if useful

urlencode: urlencode,
base64enc: base64enc,
}),
adapter: new HandlebarsAdapter(handlebarsHelpers),
Copy link
Member

Choose a reason for hiding this comment

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

for a later PR maybe, should we move the content of useFactory to a dedicated mailer factory class/file?

Copy link
Member Author

Choose a reason for hiding this comment

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

Agreed. It is getting rather long. It might make sense to wrap handlebars too. Currently you need to remember to register helpers if you call hb directly from outside of a module (eg during testing).

@sbliven sbliven force-pushed the email-ignoreerrors branch from e995ad6 to 522245d Compare October 20, 2025 09:10
Also some test cleanup:
- Rename testing job template to make it obviously test-only
- Remove some optional fields with default values from mock datasets and jobs
Fixes:
- improve error message in the switch regex case
- flatten Job objects in update notifications

Changes:
- Add an example job config for sending emails only for finished jobs

Features:
- Add 'matches' and 'default' handlebars helpers
Previously HTTP error codes were ignored but network errors or templating errors
still caused exceptions. Now these should all be caught.
@sbliven sbliven force-pushed the email-ignoreerrors branch from 522245d to 70a0bb3 Compare October 20, 2025 15:04
@sbliven sbliven enabled auto-merge (squash) October 20, 2025 15:04
@sbliven sbliven merged commit 15a1161 into master Oct 20, 2025
13 checks passed
@sbliven sbliven deleted the email-ignoreerrors branch October 20, 2025 15:12
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.

2 participants