|
| 1 | +--- |
| 2 | +title: Validation Steps |
| 3 | +description: Use explicit validation steps to fail fast on invalid input |
| 4 | +sidebar: |
| 5 | + order: 30 |
| 6 | +--- |
| 7 | + |
| 8 | +import { Aside } from '@astrojs/starlight/components'; |
| 9 | + |
| 10 | +Validation steps catch invalid input early, before expensive operations run. Structure them to fail fast with no retries. |
| 11 | + |
| 12 | +## Why Explicit Validation Steps? |
| 13 | + |
| 14 | +pgflow retries all exceptions based on `maxAttempts`. Without explicit validation, input errors waste retry attempts: |
| 15 | + |
| 16 | +```typescript |
| 17 | +// Without validation - wastes retry attempts on invalid input |
| 18 | +new Flow<{ email: string }>({ slug: 'sendEmail', maxAttempts: 5 }) |
| 19 | + .step( |
| 20 | + { slug: 'send' }, |
| 21 | + async (input) => { |
| 22 | + if (!input.run.email.includes('@')) { |
| 23 | + throw new Error('Invalid email'); // Retries 5 times! |
| 24 | + } |
| 25 | + return await sendEmail(input.run.email); |
| 26 | + } |
| 27 | + ) |
| 28 | +``` |
| 29 | + |
| 30 | +With explicit validation, failures stop immediately: |
| 31 | + |
| 32 | +```typescript |
| 33 | +// With validation - fails immediately on invalid input |
| 34 | +new Flow<{ email: string }>({ slug: 'sendEmail' }) |
| 35 | + .step( |
| 36 | + { slug: 'validInput', maxAttempts: 1 }, |
| 37 | + (input) => { |
| 38 | + if (!input.run.email.includes('@')) { |
| 39 | + throw new Error('Invalid email'); |
| 40 | + } |
| 41 | + return input.run; |
| 42 | + } |
| 43 | + ) |
| 44 | + .step( |
| 45 | + { slug: 'send', dependsOn: ['validInput'], maxAttempts: 5 }, |
| 46 | + async (input) => await sendEmail(input.validInput.email) |
| 47 | + ) |
| 48 | +``` |
| 49 | + |
| 50 | +## Keep Validation Synchronous |
| 51 | + |
| 52 | +Validation steps should be fast, synchronous functions that check input format and structure. Avoid async operations like database queries or API calls - those belong in separate steps with appropriate retry configuration. |
| 53 | + |
| 54 | +```typescript |
| 55 | +// Good: Fast, synchronous validation |
| 56 | +.step( |
| 57 | + { slug: 'validOrder', maxAttempts: 1 }, |
| 58 | + (input) => { |
| 59 | + const { amount, items } = input.run; |
| 60 | + |
| 61 | + if (amount <= 0) throw new Error('amount must be positive'); |
| 62 | + if (!items?.length) throw new Error('items cannot be empty'); |
| 63 | + |
| 64 | + return input.run; |
| 65 | + } |
| 66 | +) |
| 67 | + |
| 68 | +// Bad: Async checks in validation |
| 69 | +.step( |
| 70 | + { slug: 'validCustomer', maxAttempts: 1 }, |
| 71 | + async (input) => { |
| 72 | + // Database lookups belong in separate steps with retries |
| 73 | + const exists = await checkCustomerExists(input.run.customerId); |
| 74 | + if (!exists) throw new Error('Customer not found'); |
| 75 | + return input.run; |
| 76 | + } |
| 77 | +) |
| 78 | +``` |
| 79 | + |
| 80 | +<Aside type="tip"> |
| 81 | +Validation steps check **format and structure** (email format, positive numbers, array length). Existence checks and external validations belong in regular steps with retry configuration. |
| 82 | +</Aside> |
| 83 | + |
| 84 | +## See Also |
| 85 | + |
| 86 | +- [Retrying Steps](/build/retrying-steps/) - Understanding failure types and retry policies |
| 87 | +- [Context Object](/concepts/context-object/) - Accessing validated input in dependent steps |
0 commit comments