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

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
@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
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
@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.

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.

1 participant