-
### Unvalidated input A forum participant examines a simple case.
-
A manual trigger passes zero items or two or more items to HTTP Request. Zero produces an invalid call.
-
Two or more turn into a batch of requests that nobody planned to pay for.
-
The solution is one Code node between the trigger and the request: it requires exactly one input item and stops the workflow with an error for any other number. The principle applies beyond this example.
-
If a request costs money (a paid API, sending to a client, or a charge), the input data must be validated beforehand. This is twice as important with LLMs: the model returns a plausible-looking structure, and the code must validate it. ###
-
Duplicates and race conditions The discussion of a salon reminder and waiting-list system provides a useful reference point.
-
The conditional UPDATE is itself a state transition: `UPDATE slots SET state = 'Filled', phone = $1 WHERE slot_start = $2 AND state = 'Offered'` will return one row to the winner and zero to everyone else.
-
The “picked up” and “late” statuses are determined by the number of affected rows; no separate logic is needed.
-
The same approach works further along the chain: the “Reserved → Reminded” transition
-
runs only if the record is still in the “Reserved” state.
-
Two parallel runs will no longer send the client two messages. ### Errors without alerts
-
A workflow without an error handler fails silently, and the client who did not receive an email or invoice reports the problem. Unlimited retries have the opposite effect: the failed call repeats until the quota runs out.
-
Therefore, a production workflow must have its timeout, retry count, and alert recipient defined in advance.
