Link automation.action.* events to automation.triggered event#2
Conversation
When debugging automation failures at high volumes, it's difficult to trace from an `automation.action.failed` event back to the `automation.triggered` event that spawned it. This adds an `automation_triggered_event_id` field to `TriggeredAction` and includes it as a related resource with role `automation-triggered-event` on all action events (`.triggered`, `.executed`, and `.failed`). Port of https://github.com/PrefectHQ/nebula/pull/10911 Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
The triggering-event related resource should appear on all three action event types (.triggered, .executed, .failed) to enable full traceability. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Now that automation.action.executed and automation.action.failed events include a triggering-event related resource, update the tests to expect it in their assertions. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Build related_resources once at the start of fail() and succeed() methods and reuse it for both the .triggered and .failed/.executed events, rather than building separate lists with identical logic. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Add a brief section to the automations docs explaining the events emitted during automation execution and the related resources (triggering-event and automation-triggered-event) available for tracing action failures back to their source. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
This PR adds functionality to link automation action events back to the automation.triggered or automation.resolved events that prompted them. This enables better tracing from action failures back to their originating automation trigger events.
Changes:
- Added
automation_triggered_event_idfield to theTriggeredActionschema to store the ID of the automation.triggered/resolved event - Updated the triggers service to propagate the automation state change event ID when creating triggered actions
- Modified action event emission to include both
automation-triggered-eventandtriggering-eventrelated resources - Added comprehensive test coverage for the new linking functionality
- Added documentation explaining how to trace automation actions through related events
Reviewed changes
Copilot reviewed 16 out of 16 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| src/prefect/server/events/schemas/automations.py | Added automation_triggered_event_id field and validator to TriggeredAction model |
| src/prefect/server/events/triggers.py | Updated to determine and propagate the primary state change event ID to triggered actions |
| src/prefect/server/events/actions.py | Modified to include automation-triggered-event and triggering-event related resources on action events |
| tests/events/server/triggers/test_service.py | Updated tests to verify automation_triggered_event_id is set correctly |
| tests/events/server/actions/test_actions_service.py | Added comprehensive tests for the new linking functionality with and without automation_triggered_event_id |
| tests/events/server/actions/test_*.py | Updated action-specific tests to verify triggering-event related resources are included |
| docs/v3/concepts/automations.mdx | Added documentation section explaining event tracing with related resource roles |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| event="prefect.automation.action.triggered", | ||
| resource=resource, | ||
| related=related_resources, | ||
| related=self._resulting_related_resources, |
There was a problem hiding this comment.
The action.triggered event in the fail method is using self._resulting_related_resources instead of related_resources. This means the action.triggered event will not include the automation-triggered-event and triggering-event related resources that were just constructed.
This is inconsistent with the succeed method where both the action.triggered and action.executed events correctly use related_resources. The action.triggered event should include these links so users can trace from the triggered event back to the automation.triggered event and original triggering event.
| related=self._resulting_related_resources, | |
| related=related_resources, |
| """Ensure automation_triggered_event_id is only set when triggering_event exists.""" | ||
| if v is not None and info.data.get("triggering_event") is None: | ||
| raise ValueError( | ||
| "automation_triggered_event_id can only be set when triggering_event is provided" | ||
| ) |
There was a problem hiding this comment.
The validator logic is incorrect. It prevents automation_triggered_event_id from being set when triggering_event is None. However, proactive triggers (like metric thresholds or time-based triggers) don't have an original triggering event, but they still emit automation.triggered events and should be able to link action events back to those automation state change events.
The automation_triggered_event_id field refers to the automation.triggered or automation.resolved event, not the original triggering event, so it should be allowed to be set independently of whether triggering_event exists.
| """Ensure automation_triggered_event_id is only set when triggering_event exists.""" | |
| if v is not None and info.data.get("triggering_event") is None: | |
| raise ValueError( | |
| "automation_triggered_event_id can only be set when triggering_event is provided" | |
| ) | |
| """Allow automation_triggered_event_id to be set independently of triggering_event.""" |
Benchmark PR from agentic-review-benchmarks#2