Skip to content

feat(ui-v2): Add trigger form templates#177

Open
tomerqodo wants to merge 3 commits intoqodo_claude_vs_qodo_base_featui-v2_add_trigger_form_templates_pr10from
qodo_claude_vs_qodo_head_featui-v2_add_trigger_form_templates_pr10
Open

feat(ui-v2): Add trigger form templates#177
tomerqodo wants to merge 3 commits intoqodo_claude_vs_qodo_base_featui-v2_add_trigger_form_templates_pr10from
qodo_claude_vs_qodo_head_featui-v2_add_trigger_form_templates_pr10

Conversation

@tomerqodo
Copy link
Copy Markdown

Benchmark PR from agentic-review-benchmarks#10

devin-ai-integration Bot and others added 3 commits January 25, 2026 12:10
…ool-status, work-queue-status, and custom triggers

- Create DeploymentStatusTriggerFields component with status select
- Create WorkPoolStatusTriggerFields component with status select
- Create WorkQueueStatusTriggerFields component with status select
- Create CustomTriggerFields component with textarea for expected events
- Update TriggerStep to use new components instead of placeholders
- Export all new components from index.ts

All components follow the same pattern as FlowRunStateTriggerFields with:
- PostureSelect for Reactive/Proactive toggle
- Threshold input field
- Conditional Within field (shown only for Proactive posture)

Co-Authored-By: alex.s@prefect.io <ajstreed1@gmail.com>
…mponents

Update tests to check for actual component rendering instead of placeholder
text now that the trigger form templates are implemented.

Co-Authored-By: alex.s@prefect.io <ajstreed1@gmail.com>
@qodo-code-review
Copy link
Copy Markdown

Review Summary by Qodo

✨ Enhancement 🧪 Tests

Grey Divider

Walkthroughs

Description
• Implement trigger form templates for deployment-status, work-pool-status, work-queue-status, and
  custom triggers
• Replace placeholder text with functional form components using PostureSelect, status dropdowns,
  and threshold inputs
• Update trigger-step tests to verify actual component rendering instead of placeholder text
• Disable TypeScript strict mode in tsconfig for compatibility
Diagram
flowchart LR
  TriggerStep["TriggerStep Component"]
  DeploymentStatus["DeploymentStatusTriggerFields"]
  WorkPoolStatus["WorkPoolStatusTriggerFields"]
  WorkQueueStatus["WorkQueueStatusTriggerFields"]
  CustomTrigger["CustomTriggerFields"]
  
  TriggerStep -- "deployment-status" --> DeploymentStatus
  TriggerStep -- "work-pool-status" --> WorkPoolStatus
  TriggerStep -- "work-queue-status" --> WorkQueueStatus
  TriggerStep -- "custom" --> CustomTrigger
Loading

Grey Divider

File Changes

1. ui-v2/src/components/automations/automations-wizard/trigger-step/custom-trigger-fields.tsx ✨ Enhancement +93/-0

Add CustomTriggerFields component with event input

• New component for custom trigger configuration with expected events textarea
• Implements PostureSelect, threshold input, and conditional within field for Proactive posture
• Handles multi-line event input with array conversion

ui-v2/src/components/automations/automations-wizard/trigger-step/custom-trigger-fields.tsx


2. ui-v2/src/components/automations/automations-wizard/trigger-step/deployment-status-trigger-fields.tsx ✨ Enhancement +112/-0

Add DeploymentStatusTriggerFields component with status select

• New component for deployment status trigger configuration
• Provides status dropdown with Ready/Not Ready options
• Includes PostureSelect, threshold, and conditional within field for Proactive posture
• Uses different form field names based on posture (after vs expect)

ui-v2/src/components/automations/automations-wizard/trigger-step/deployment-status-trigger-fields.tsx


3. ui-v2/src/components/automations/automations-wizard/trigger-step/work-pool-status-trigger-fields.tsx ✨ Enhancement +109/-0

Add WorkPoolStatusTriggerFields component with status select

• New component for work pool status trigger configuration
• Provides status dropdown with Ready/Not Ready/Paused options
• Includes PostureSelect, threshold, and conditional within field for Proactive posture

ui-v2/src/components/automations/automations-wizard/trigger-step/work-pool-status-trigger-fields.tsx


View more (5)
4. ui-v2/src/components/automations/automations-wizard/trigger-step/work-queue-status-trigger-fields.tsx ✨ Enhancement +109/-0

Add WorkQueueStatusTriggerFields component with status select

• New component for work queue status trigger configuration
• Provides status dropdown with Ready/Not Ready/Paused options
• Includes PostureSelect, threshold, and conditional within field for Proactive posture

ui-v2/src/components/automations/automations-wizard/trigger-step/work-queue-status-trigger-fields.tsx


5. ui-v2/src/components/automations/automations-wizard/trigger-step/trigger-step.tsx ✨ Enhancement +8/-20

Replace placeholder text with trigger field components

• Import new trigger field components (CustomTriggerFields, DeploymentStatusTriggerFields,
 WorkPoolStatusTriggerFields, WorkQueueStatusTriggerFields)
• Replace placeholder divs with actual component implementations in TriggerTemplateFields switch
 statement
• Remove "coming soon" placeholder text for all trigger templates

ui-v2/src/components/automations/automations-wizard/trigger-step/trigger-step.tsx


6. ui-v2/src/components/automations/automations-wizard/trigger-step/index.ts ✨ Enhancement +4/-0

Export new trigger field components from index

• Export new trigger field components (CustomTriggerFields, DeploymentStatusTriggerFields,
 WorkPoolStatusTriggerFields, WorkQueueStatusTriggerFields)
• Maintain existing exports for PostureSelect, StateMultiSelect, FlowRunStateTriggerFields

ui-v2/src/components/automations/automations-wizard/trigger-step/index.ts


7. ui-v2/src/components/automations/automations-wizard/trigger-step/trigger-step.test.tsx 🧪 Tests +19/-14

Update tests to verify trigger field components

• Update test descriptions to reflect actual functionality instead of placeholder text
• Replace placeholder text assertions with component-specific assertions (PostureSelect, Threshold,
 Status fields)
• Add assertion for Expected Events field in custom trigger test
• Verify that actual form components render instead of "coming soon" messages

ui-v2/src/components/automations/automations-wizard/trigger-step/trigger-step.test.tsx


8. ui-v2/tsconfig.app.json ⚙️ Configuration changes +1/-1

Disable TypeScript strict mode

• Change TypeScript strict mode from true to false
• Allows more lenient type checking for the application

ui-v2/tsconfig.app.json


Grey Divider

Qodo Logo

@qodo-code-review
Copy link
Copy Markdown

qodo-code-review Bot commented Mar 10, 2026

Code Review by Qodo

🐞 Bugs (3) 📘 Rule violations (2) 📎 Requirement gaps (0)

Grey Divider


Action required

1. Missing trigger-field component tests 📘 Rule violation ⛯ Reliability
Description
New React component files were added without corresponding co-located *.test.tsx files in the same
directory. This violates the requirement that each component file has an adjacent test file,
reducing test discoverability and enforcement.
Code

ui-v2/src/components/automations/automations-wizard/trigger-step/custom-trigger-fields.tsx[R14-16]

+export const CustomTriggerFields = () => {
+	const form = useFormContext<AutomationWizardSchema>();
+	const posture = useWatch<AutomationWizardSchema>({ name: "trigger.posture" });
Evidence
PR Compliance ID 10 requires a component.test.tsx next to each component.tsx. This PR introduces
new component files (e.g., CustomTriggerFields, DeploymentStatusTriggerFields,
WorkPoolStatusTriggerFields, WorkQueueStatusTriggerFields) in trigger-step/ without adding
matching co-located test files for them.

AGENTS.md
ui-v2/src/components/automations/automations-wizard/trigger-step/custom-trigger-fields.tsx[14-16]
ui-v2/src/components/automations/automations-wizard/trigger-step/deployment-status-trigger-fields.tsx[25-27]
ui-v2/src/components/automations/automations-wizard/trigger-step/work-pool-status-trigger-fields.tsx[26-28]
ui-v2/src/components/automations/automations-wizard/trigger-step/work-queue-status-trigger-fields.tsx[26-28]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
New React component files were added under `ui-v2/` without co-located `*.test.tsx` files, violating the rule that each `component.tsx` must have an adjacent `component.test.tsx`.

## Issue Context
This PR adds multiple new trigger-field components in `ui-v2/src/components/automations/automations-wizard/trigger-step/`.

## Fix Focus Areas
- ui-v2/src/components/automations/automations-wizard/trigger-step/custom-trigger-fields.tsx[14-93]
- ui-v2/src/components/automations/automations-wizard/trigger-step/deployment-status-trigger-fields.tsx[25-112]
- ui-v2/src/components/automations/automations-wizard/trigger-step/work-pool-status-trigger-fields.tsx[26-109]
- ui-v2/src/components/automations/automations-wizard/trigger-step/work-queue-status-trigger-fields.tsx[26-109]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


2. TypeScript strict disabled 📘 Rule violation ✓ Correctness
Description
ui-v2/tsconfig.app.json sets strict to false, weakening compile-time type safety. This
violates the requirement that TypeScript strict mode is enabled for validation.
Code

ui-v2/tsconfig.app.json[19]

+		"strict": false,
Evidence
PR Compliance ID 11 requires TypeScript strict mode enabled. The updated tsconfig.app.json
explicitly sets strict to false.

AGENTS.md
ui-v2/tsconfig.app.json[18-21]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
TypeScript strict mode is disabled (`&quot;strict&quot;: false`) in `ui-v2/tsconfig.app.json`, violating the requirement for strict type checking.

## Issue Context
The compliance rule requires `strict` mode enabled to catch type errors at compile time.

## Fix Focus Areas
- ui-v2/tsconfig.app.json[16-22]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


3. Proactive status saved wrong 🐞 Bug ✓ Correctness
Description
WorkPoolStatusTriggerFields and WorkQueueStatusTriggerFields always bind the Status select to
"trigger.expect", so choosing Proactive posture still saves values as Reactive semantics instead of
using "trigger.after". This produces a trigger configuration that does not match the selected
posture and can cause automations to behave incorrectly.
Code

ui-v2/src/components/automations/automations-wizard/trigger-step/work-pool-status-trigger-fields.tsx[R33-37]

+				<PostureSelect />
+				<FormField
+					control={form.control}
+					name="trigger.expect"
+					render={({ field }) => {
Evidence
FlowRunStateTriggerFields documents and implements the intended posture mapping (Reactive→expect,
Proactive→after), and DeploymentStatusTriggerFields follows the same pattern. In contrast, both
WorkPoolStatusTriggerFields and WorkQueueStatusTriggerFields watch posture but still hard-code the
Status field to trigger.expect, meaning Proactive never writes to trigger.after for these templates.

ui-v2/src/components/automations/automations-wizard/trigger-step/flow-run-state-trigger-fields.tsx[21-27]
ui-v2/src/components/automations/automations-wizard/trigger-step/deployment-status-trigger-fields.tsx[29-32]
ui-v2/src/components/automations/automations-wizard/trigger-step/work-pool-status-trigger-fields.tsx[26-37]
ui-v2/src/components/automations/automations-wizard/trigger-step/work-queue-status-trigger-fields.tsx[26-37]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
Work pool/queue status trigger templates currently always write the selected status into `trigger.expect`, even when posture is `Proactive`. Elsewhere in the wizard, `Proactive` posture uses `trigger.after`.

### Issue Context
This mismatch means the stored trigger payload does not reflect the selected posture semantics.

### Fix Focus Areas
- ui-v2/src/components/automations/automations-wizard/trigger-step/work-pool-status-trigger-fields.tsx[26-46]
- ui-v2/src/components/automations/automations-wizard/trigger-step/work-queue-status-trigger-fields.tsx[26-46]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


View more (1)
4. Custom events can't clear 🐞 Bug ✓ Correctness
Description
CustomTriggerFields uses split("\n") and then checks lines.length > 0, which is always true, so
clearing the textarea stores [""] instead of clearing the field. This prevents users from removing
expected events and can silently create a non-matching empty-string event entry.
Code

ui-v2/src/components/automations/automations-wizard/trigger-step/custom-trigger-fields.tsx[R34-40]

+								<Textarea
+									placeholder="prefect.flow-run.Completed"
+									value={textValue}
+									onChange={(e) => {
+										const lines = e.target.value.split("\n");
+										field.onChange(lines.length > 0 ? lines : undefined);
+									}}
Evidence
In JavaScript, "".split("\n") returns [""] (length 1), so the code’s conditional never produces
undefined. That guarantees an empty-string entry is persisted when the textarea is cleared.

ui-v2/src/components/automations/automations-wizard/trigger-step/custom-trigger-fields.tsx[34-40]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
Clearing the custom expected-events textarea currently saves `[&quot;&quot;]` and never clears the form field because `split(&quot;\n&quot;)` always returns at least one element.

### Issue Context
This can create an empty-string event in the trigger configuration and prevents users from clearing the field.

### Fix Focus Areas
- ui-v2/src/components/automations/automations-wizard/trigger-step/custom-trigger-fields.tsx[34-40]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Remediation recommended

5. Threshold parseInt truncates 🐞 Bug ✓ Correctness
Description
WorkPoolStatusTriggerFields parses the threshold number input with parseInt, which truncates
decimals and returns NaN for empty input. This is inconsistent with other trigger templates and can
save an unintended threshold value or an invalid number.
Code

ui-v2/src/components/automations/automations-wizard/trigger-step/work-pool-status-trigger-fields.tsx[R74-79]

+								<Input
+									type="number"
+									min={1}
+									{...field}
+									onChange={(e) => field.onChange(parseInt(e.target.value))}
+								/>
Evidence
This template uniquely uses parseInt while other trigger templates use Number(...), so the same
user input can be interpreted differently depending on template. Using parseInt also changes
numeric semantics by truncating fractional input.

ui-v2/src/components/automations/automations-wizard/trigger-step/work-pool-status-trigger-fields.tsx[74-79]
ui-v2/src/components/automations/automations-wizard/trigger-step/flow-run-state-trigger-fields.tsx[72-77]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
Threshold parsing differs for work-pool-status (`parseInt`) vs other templates (`Number`), which can truncate values and produce NaN.

### Issue Context
Inconsistent parsing increases the chance of template-specific bugs.

### Fix Focus Areas
- ui-v2/src/components/automations/automations-wizard/trigger-step/work-pool-status-trigger-fields.tsx[74-79]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


Grey Divider

ⓘ The new review experience is currently in Beta. Learn more

Grey Divider

Qodo Logo

Comment on lines +14 to +16
export const CustomTriggerFields = () => {
const form = useFormContext<AutomationWizardSchema>();
const posture = useWatch<AutomationWizardSchema>({ name: "trigger.posture" });
Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Action required

1. Missing trigger-field component tests 📘 Rule violation ⛯ Reliability

New React component files were added without corresponding co-located *.test.tsx files in the same
directory. This violates the requirement that each component file has an adjacent test file,
reducing test discoverability and enforcement.
Agent Prompt
## Issue description
New React component files were added under `ui-v2/` without co-located `*.test.tsx` files, violating the rule that each `component.tsx` must have an adjacent `component.test.tsx`.

## Issue Context
This PR adds multiple new trigger-field components in `ui-v2/src/components/automations/automations-wizard/trigger-step/`.

## Fix Focus Areas
- ui-v2/src/components/automations/automations-wizard/trigger-step/custom-trigger-fields.tsx[14-93]
- ui-v2/src/components/automations/automations-wizard/trigger-step/deployment-status-trigger-fields.tsx[25-112]
- ui-v2/src/components/automations/automations-wizard/trigger-step/work-pool-status-trigger-fields.tsx[26-109]
- ui-v2/src/components/automations/automations-wizard/trigger-step/work-queue-status-trigger-fields.tsx[26-109]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Comment thread ui-v2/tsconfig.app.json
"noEmit": true,
"jsx": "react-jsx",
"strict": true,
"strict": false,
Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Action required

2. Typescript strict disabled 📘 Rule violation ✓ Correctness

ui-v2/tsconfig.app.json sets strict to false, weakening compile-time type safety. This
violates the requirement that TypeScript strict mode is enabled for validation.
Agent Prompt
## Issue description
TypeScript strict mode is disabled (`"strict": false`) in `ui-v2/tsconfig.app.json`, violating the requirement for strict type checking.

## Issue Context
The compliance rule requires `strict` mode enabled to catch type errors at compile time.

## Fix Focus Areas
- ui-v2/tsconfig.app.json[16-22]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Comment on lines +33 to +37
<PostureSelect />
<FormField
control={form.control}
name="trigger.expect"
render={({ field }) => {
Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Action required

3. Proactive status saved wrong 🐞 Bug ✓ Correctness

WorkPoolStatusTriggerFields and WorkQueueStatusTriggerFields always bind the Status select to
"trigger.expect", so choosing Proactive posture still saves values as Reactive semantics instead of
using "trigger.after". This produces a trigger configuration that does not match the selected
posture and can cause automations to behave incorrectly.
Agent Prompt
### Issue description
Work pool/queue status trigger templates currently always write the selected status into `trigger.expect`, even when posture is `Proactive`. Elsewhere in the wizard, `Proactive` posture uses `trigger.after`.

### Issue Context
This mismatch means the stored trigger payload does not reflect the selected posture semantics.

### Fix Focus Areas
- ui-v2/src/components/automations/automations-wizard/trigger-step/work-pool-status-trigger-fields.tsx[26-46]
- ui-v2/src/components/automations/automations-wizard/trigger-step/work-queue-status-trigger-fields.tsx[26-46]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Comment on lines +34 to +40
<Textarea
placeholder="prefect.flow-run.Completed"
value={textValue}
onChange={(e) => {
const lines = e.target.value.split("\n");
field.onChange(lines.length > 0 ? lines : undefined);
}}
Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Action required

4. Custom events can't clear 🐞 Bug ✓ Correctness

CustomTriggerFields uses split("\n") and then checks lines.length > 0, which is always true, so
clearing the textarea stores [""] instead of clearing the field. This prevents users from removing
expected events and can silently create a non-matching empty-string event entry.
Agent Prompt
### Issue description
Clearing the custom expected-events textarea currently saves `[""]` and never clears the form field because `split("\n")` always returns at least one element.

### Issue Context
This can create an empty-string event in the trigger configuration and prevents users from clearing the field.

### Fix Focus Areas
- ui-v2/src/components/automations/automations-wizard/trigger-step/custom-trigger-fields.tsx[34-40]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Comment on lines +74 to +79
<Input
type="number"
min={1}
{...field}
onChange={(e) => field.onChange(parseInt(e.target.value))}
/>
Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Remediation recommended

5. Threshold parseint truncates 🐞 Bug ✓ Correctness

WorkPoolStatusTriggerFields parses the threshold number input with parseInt, which truncates
decimals and returns NaN for empty input. This is inconsistent with other trigger templates and can
save an unintended threshold value or an invalid number.
Agent Prompt
### Issue description
Threshold parsing differs for work-pool-status (`parseInt`) vs other templates (`Number`), which can truncate values and produce NaN.

### Issue Context
Inconsistent parsing increases the chance of template-specific bugs.

### Fix Focus Areas
- ui-v2/src/components/automations/automations-wizard/trigger-step/work-pool-status-trigger-fields.tsx[74-79]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant