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
When starting flows or retrieving runs, the client waits for a [`realtimeStabilizationDelayMs`](/reference/pgflow-client/#constructor) delay (default: `300ms`) after subscribing to Realtime channels. This works around a [known Supabase Realtime limitation](https://github.com/supabase/supabase-js/issues/1599) where backend routing isn't fully established when the SUBSCRIBED event is emitted.
57
+
58
+
**If you experience missed events or connection issues, increase this value to `400-500ms`:**
59
+
60
+
```typescript
61
+
const pgflow =newPgflowClient(supabase, {
62
+
realtimeStabilizationDelayMs: 400,
63
+
});
64
+
```
65
+
66
+
You can also disable the delay by setting it to `0`, though this may cause missed events in some environments:
67
+
68
+
```typescript
69
+
const pgflow =newPgflowClient(supabase, {
70
+
realtimeStabilizationDelayMs: 0,
71
+
});
72
+
```
73
+
:::
74
+
55
75
The simplest pattern is to start a workflow and wait for it to complete:
pgflow 0.7.3 introduces a configurable `realtimeStabilizationDelayMs` option that addresses a known Supabase Realtime limitation where backend routing isn't fully established when the SUBSCRIBED event is emitted.
18
+
19
+
## What's New
20
+
21
+
The TypeScript client now includes a `realtimeStabilizationDelayMs` configuration option (default: 300ms) that adds a delay after subscribing to Realtime channels. This works around a [known Supabase Realtime issue](https://github.com/supabase/supabase-js/issues/1599) where messages sent immediately after subscription confirmation may be missed because backend routing takes additional time to fully establish.
22
+
23
+
**When starting flows or retrieving runs**, the client waits for this stabilization period after receiving the SUBSCRIBED event, ensuring that all subsequent realtime events are properly received.
24
+
25
+
## Configuration
26
+
27
+
The default 300ms delay works reliably in most environments. If you experience missed events or connection issues, increase the delay to 400-500ms:
28
+
29
+
```typescript
30
+
import { PgflowClient } from'@pgflow/client';
31
+
32
+
// Increase stabilization delay for unreliable connections
33
+
const pgflow =newPgflowClient(supabase, {
34
+
realtimeStabilizationDelayMs: 400,
35
+
});
36
+
```
37
+
38
+
You can also disable the delay by setting it to 0, though this may cause missed events in some environments:
39
+
40
+
```typescript
41
+
// Disable delay (may cause missed events)
42
+
const pgflow =newPgflowClient(supabase, {
43
+
realtimeStabilizationDelayMs: 0,
44
+
});
45
+
```
46
+
47
+
See the [TypeScript Client documentation](/build/starting-flows/typescript-client/) and [PgflowClient API reference](/reference/pgflow-client/) for complete details.
48
+
49
+
## Upgrading
50
+
51
+
<Asidetype="note"title="No Migration Required">
52
+
This release only updates the TypeScript client package. No database migrations are needed.
53
+
</Aside>
54
+
55
+
Follow the [update guide](/deploy/update-pgflow/) to upgrade your `@pgflow/client` dependency to 0.7.3.
56
+
57
+
---
58
+
59
+
**Questions or issues?** Join our [Discord community](https://www.pgflow.dev/discord/) or [open an issue on GitHub](https://github.com/pgflow-dev/pgflow/issues).
Delay in milliseconds after subscribing to Supabase Realtime channels. This addresses a known Supabase Realtime limitation where the backend routing isn't fully established when the SUBSCRIBED event is emitted. Increase to `400-500ms` if experiencing missed events or connection issues.
44
51
45
52
### Methods
46
53
@@ -110,24 +117,35 @@ Represents a single flow execution instance.
110
117
|`status`|`FlowRunStatus`| Current run status |
111
118
|`input`|`object`| Flow input data |
112
119
|`output`|`object \| null`| Flow output data (available when completed) |
120
+
|`error`|`Error \| null`| Error object (available when failed) |
113
121
|`error_message`|`string \| null`| Error message (available when failed) |
114
122
|`started_at`|`Date \| null`| Timestamp when run started |
115
-
|`completed_at`|`Date \| null`| Timestamp when run completed or failed |
123
+
|`completed_at`|`Date \| null`| Timestamp when run completed |
124
+
|`failed_at`|`Date \| null`| Timestamp when run failed |
125
+
|`remaining_steps`|`number`| Number of steps remaining to complete |
116
126
117
127
### Methods
118
128
119
129
#### `waitForStatus(status, options?)`
120
130
121
-
Waits for the run to reach a specific status or one of multiple statuses.
131
+
Waits for the run to reach a terminal status (completed or failed).
122
132
123
133
**Parameters:**
124
134
125
135
| Parameter | Type | Required | Description |
126
136
|-----------|------|----------|-------------|
127
-
|`status`|`FlowRunStatus \| FlowRunStatus[]`| Yes | Target status or array of statuses|
137
+
|`status`|`'completed' \| 'failed'`| Yes | Target terminal status to wait for|
128
138
|`options`|`object`| No | Wait options |
129
-
|`options.timeoutMs`|`number`| No | Timeout in milliseconds |
130
-
|`options.signal`|`AbortSignal`| No | Abort signal to cancel waiting |
0 commit comments