You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: site/src/content/docs/concepts/expressions.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -54,7 +54,7 @@ Every step exposes an `error` field:
54
54
- **`null`** — The step succeeded or was skipped (its `if` condition was false).
55
55
- **String message** — The step failed. The error message is populated from the connector.
56
56
57
-
The error field is available regardless of whether the step has `continue_on_error` enabled. Use it to implement conditional error handling:
57
+
The `error` field is always present in the CEL context for any step. However, it is only practically useful when the referenced step has `continue_on_error: true`. Without that flag, a step failure halts the entire workflow before any downstream step can run — so there is no opportunity to check the error. Use `continue_on_error: true` on any step whose failure you want to handle in subsequent steps:
|`poll_interval`| string | No | How often to check for new messages (e.g., `30s`, `5m`). Default: `60s`. |
206
206
207
207
### Trigger Context Variables
@@ -242,20 +242,32 @@ steps:
242
242
text: "New email from {{ trigger.from }}: {{ trigger.subject }}"
243
243
```
244
244
245
-
### Connection Management
245
+
### At-Least-Once Delivery
246
246
247
-
Email triggers maintain persistent IMAP connections to reduce authentication overhead. By default, Mantle pools up to 5 concurrent connections per mailbox credential.
247
+
The email trigger marks messages as seen **after** firing the workflow for each message. If the Mantle process crashes or is restarted mid-poll, messages that were fetched but not yet marked may be re-triggered on the next poll cycle. This means email-triggered workflows may receive the same message more than once.
248
248
249
-
**Configuring connection limits in `mantle.yaml`:**
249
+
Design email-triggered workflows to be idempotent. A reliable approach is to deduplicate on `trigger.message_id`:
250
250
251
251
```yaml
252
-
engine:
253
-
email:
254
-
max_connections: 10 # Default: 5
255
-
connection_timeout: 30s # Default: 30s
256
-
idle_timeout: 5m # Default: 5m
252
+
steps:
253
+
- name: check-duplicate
254
+
action: postgres/query
255
+
credential: my-database
256
+
params:
257
+
query: "INSERT INTO processed_emails (message_id) VALUES ($1) ON CONFLICT DO NOTHING"
Email triggers maintain persistent IMAP connections to reduce authentication overhead. By default, Mantle pools up to 5 concurrent connections per mailbox credential. This limit is a compile-time default in v0.3.0 and is not runtime-configurable via `mantle.yaml`.
270
+
259
271
### Provider Limits
260
272
261
273
Email providers have different concurrency limits. Plan your poll intervals accordingly:
@@ -293,4 +305,4 @@ triggers:
293
305
poll_interval: 60s
294
306
```
295
307
296
-
Each workflow gets its own connection, but they share the pool. If latency is a concern, stagger poll intervals or increase `max_connections` in `mantle.yaml`.
308
+
Each workflow gets its own connection, but they share the pool. If latency is a concern, stagger poll intervals.
**Authentication:** Credentials are provided via the step-level `credential` field. The email connector reads `username`, `password`, `host`, and `port` from the credential (IMAP-compatible).
343
+
343
344
**Example:**
344
345
345
346
```yaml
@@ -364,16 +365,17 @@ Moves an email message to a different folder.
364
365
| `uid` | number | Yes | IMAP UID of the message. |
Copy file name to clipboardExpand all lines: site/src/content/docs/workflow-reference/index.md
+6-2Lines changed: 6 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -253,7 +253,7 @@ steps:
253
253
254
254
### Available Error Fields
255
255
256
-
- **`steps['name'].error`** — `null` for successful or skipped steps; a string error message for failed steps. Available for all steps regardless of `continue_on_error`.
256
+
- **`steps['name'].error`** — `null` for successful or skipped steps; a string error message for failed steps. The field is always present in the CEL context, but is only practically reachable on a step that has `continue_on_error: true` — without that flag, a step failure halts the workflow before any downstream step can inspect the error.
257
257
- **`steps['name'].output`** — Partial output available from the failed step if the connector provided it. Structure depends on the connector.
258
258
259
259
### Example: Fallback Pattern
@@ -355,9 +355,13 @@ Triggers are optional. Without them, the workflow can still be executed manually
0 commit comments