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
console.log(`Using ${safeTimeout}ms timeout based on worker visibility timeout`);
240
-
241
-
const response =awaitfetch(input.url, {
242
-
signal: AbortSignal.timeout(safeTimeout)
243
-
});
244
-
245
-
returnawaitresponse.json();
246
-
})
247
-
```
248
233
249
234
<Asidetype="note">
250
235
The `workerConfig` object is deeply frozen to prevent handlers from modifying configuration values that could affect other message executions. It represents the final resolved configuration with all defaults applied, not the original user input. Since all defaults have been resolved, you can safely access any field without undefined checks.
This guide explains how to update pgflow to the latest version, including package updates and database migrations. pgflow updates involve two main components that need to be updated together.
14
14
15
15
<Asidetype="caution"title="Unified Versioning">
16
-
pgflow uses changesets for version management, which means all packages are versioned together. When you update one pgflow package, all others should be updated to the same version to maintain compatibility.
16
+
All pgflow packages (npm and jsr) are versioned together. When you update one pgflow package, all others should be updated to the same version to maintain compatibility.
17
17
</Aside>
18
18
19
19
## What needs to be updated?
20
20
21
-
When updating pgflow, you need to update two types of packages:
21
+
When updating pgflow, you need to update:
22
22
23
23
1.**npm packages** - CLI, core libraries, client, and DSL packages
24
24
2.**JSR package** - The Edge Worker package (published to JSR registry)
@@ -31,19 +31,19 @@ When updating pgflow, you need to update two types of packages:
31
31
Update all pgflow npm packages to the latest version:
pgflow uses a simple but effective trick with two timestamps: it keeps the original timestamp in the filename so it can search for already-installed migrations in your folder, while prefixing with a new timestamp that ensures the migration appears as the newest in your Supabase migrations folder. This prevents Supabase from complaining about applying migrations with timestamps older than already-applied ones.
101
+
pgflow uses a simple but effective trick with two timestamps: it keeps the original filename in the migration it creates in your project, so it can search for already-installed migrations, while prefixing with a new timestamp that ensures the migration appears as the newest in your Supabase migrations folder. This prevents Supabase from complaining about applying migrations with timestamps older than already-applied ones.
102
102
103
103
For example, a pgflow migration `20250429164909_pgflow_initial.sql` might be installed as `20250430000010_20250429164909_pgflow_initial.sql` in your project.
104
104
</Aside>
@@ -200,4 +200,4 @@ For production updates, follow a more careful approach:
200
200
Always test pgflow updates in a non-production environment first. While pgflow migrations are designed to be safe, any database schema change carries inherent risks in production systems.
201
201
</Aside>
202
202
203
-
Your pgflow installation is now updated with the latest features, bug fixes, and database schema improvements!
203
+
Your pgflow installation is now updated with the latest features, bug fixes, and database schema improvements!
title: 'pgflow 0.6.1: Worker Configuration in Handler Context'
4
+
description: 'Handlers can now access worker configuration through context.workerConfig for intelligent decision-making based on retry limits, concurrency settings, and other worker parameters.'
5
+
date: 2025-09-05
6
+
authors:
7
+
- jumski
8
+
tags:
9
+
- release
10
+
- edge-worker
11
+
- context
12
+
- configuration
13
+
featured: true
14
+
cover:
15
+
alt: 'pgflow 0.6.1 worker config in handler context cover image'
pgflow 0.6.1 adds `workerConfig` to the handler execution context, enabling intelligent decision-making based on worker configuration.
22
+
23
+
## Worker Configuration in Context
24
+
25
+
Handlers now have access to the complete worker configuration through `context.workerConfig` ([#200](https://github.com/pgflow-dev/pgflow/issues/200)). This enables smarter handlers that can adapt their behavior based on retry limits, concurrency settings, timeouts, and other worker parameters.
See the [context documentation](/concepts/context/#workerconfig) for complete details on available configuration properties and additional examples.
42
+
43
+
44
+
## Bug Fix
45
+
46
+
This release also fixes retry strategy validation to only enforce the 50-limit cap for exponential retry strategy, allowing higher limits for fixed strategy when needed ([#199](https://github.com/pgflow-dev/pgflow/issues/199)).
47
+
48
+
## Updating to 0.6.1
49
+
50
+
Follow our [update guide](/getting-started/update-pgflow/) for step-by-step upgrade instructions.
0 commit comments