Conversation
This adds: * `FileTemplateProvider`, which serves as another way to load templates (previously env vars were the only way implemented). Expect other options in the future: load from an S3 bucket, URL, etc. * `render.py`, which serves as a simple tool / manual test for rendering templates. The idea is that (after added a main guard that calls the lambda), you can do `python my_lambda.py | python -m lambdacron.render -t template.txt -r RESULT_TYPE` and see the rendered result.
There was a problem hiding this comment.
Pull request overview
Adds a file-based template provider and a small CLI-style renderer to manually render notification templates using LambdaCron task output payloads, with accompanying tests.
Changes:
- Added
FileTemplateProviderto load Jinja2 templates from disk. - Introduced
lambdacron.renderas a CLI/module entrypoint to render templates from task-output JSON (file or stdin). - Added pytest coverage for the new renderer behavior and the file-based provider.
Reviewed changes
Copilot reviewed 5 out of 6 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
src/lambdacron/notifications/base.py |
Adds FileTemplateProvider to read template strings from a Path. |
src/lambdacron/notifications/__init__.py |
Re-exports FileTemplateProvider for public API usage. |
src/lambdacron/render.py |
New CLI/module to render templates from task output JSON via existing notification rendering logic. |
tests/test_render.py |
New tests validating CLI parsing, stdin support, strict undefined behavior, and payload extraction. |
tests/notifications/test_base.py |
Adds tests for FileTemplateProvider. |
.gitignore |
Ignores additional Python packaging artifacts (*.egg, .eggs/, *.egg-info/). |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| import argparse | ||
| import json | ||
| import sys | ||
| from pathlib import Path | ||
| from typing import Any, Mapping, TextIO | ||
|
|
||
| from jinja2 import TemplateError | ||
|
|
||
| from lambdacron.notifications.base import ( | ||
| FileTemplateProvider, | ||
| RenderedTemplateNotificationHandler, | ||
| ) |
There was a problem hiding this comment.
This module is intended to be run as python -m lambdacron.render, but src/lambdacron/ is an implicit namespace package (no __init__.py). With the current pyproject.toml using tool.setuptools.packages.find, top-level modules under lambdacron/ (like render.py) may not be included in built distributions unless namespace packages are explicitly enabled or a package lambdacron is created. Please ensure the packaging config includes this module in wheels/sdists (e.g., enable namespace package discovery or add src/lambdacron/__init__.py).
| def render_payload(self, *, payload_json: str, result_type: str) -> None: | ||
| event = { | ||
| "Records": [ | ||
| { | ||
| "body": payload_json, | ||
| "eventSource": "aws:sqs", | ||
| "messageAttributes": { | ||
| "result_type": { | ||
| "DataType": "String", | ||
| "StringValue": result_type, | ||
| } | ||
| }, | ||
| } | ||
| ] | ||
| } | ||
| self.lambda_handler(event=event, context=None) | ||
|
|
There was a problem hiding this comment.
render_payload() builds a synthetic SQS record without messageId. In RenderedTemplateNotificationHandler.lambda_handler, exceptions are only converted into batchItemFailures when messageId is present; otherwise they are re-raised. This makes the CLI tool’s success/failure behavior depend on an artificial omission and diverge from real SQS events. Consider adding a dummy messageId and then checking the returned batchItemFailures (treat any failures as a non-zero exit), or bypass lambda_handler and call the parsing/rendering path in a way that deterministically raises on render failures.
ethanholz
left a comment
ethanholz
left a comment
There was a problem hiding this comment.
I like the design but would make sure to include details cautioning the use of untrusted templates and that templates should be vetted before use. Want to get ahead of security issues with arbitrary template usage.
This adds:
FileTemplateProvider, which serves as another way to load templates (previously env vars were the only way implemented). Expect other options in the future: load from an S3 bucket, URL, etc.render.py, which serves as a simple tool / manual test for rendering templates. The idea is that (after added a main guard that calls the lambda), you can dopython my_lambda.py | python -m lambdacron.render -t template.txt -r RESULT_TYPEand see the rendered result.