Skip to content

Commit 5230a2d

Browse files
authored
docs: add 0.6.1 news post (#205)
1 parent 62d43cd commit 5230a2d

File tree

4 files changed

+66
-31
lines changed

4 files changed

+66
-31
lines changed
2.04 MB
Loading

pkgs/website/src/content/docs/concepts/context.mdx

Lines changed: 7 additions & 22 deletions
Original file line numberDiff line numberDiff line change
@@ -217,34 +217,19 @@ interface ResolvedFlowWorkerConfig {
217217
The most common use case is detecting when a message is on its final retry attempt:
218218

219219
```typescript "ctx.workerConfig" "ctx.rawMessage" ".read_ct" ".retry.limit"
220-
// Queue handler - detect final retry attempt
221-
async function processOrder(input, ctx) {
222-
const isLastRetry = ctx.rawMessage.read_ct >= ctx.workerConfig.retry.limit;
220+
async function sendEmail(input, ctx) {
221+
const isLastAttempt = ctx.rawMessage.read_ct >= ctx.workerConfig.retry.limit;
223222

224-
if (isLastRetry) {
225-
// Send alert or fallback action before final failure
226-
await sendFailureAlert(input.orderId, ctx.workerConfig.queueName);
223+
if (isLastAttempt) {
224+
// Use fallback email service on final attempt
225+
return await sendWithFallbackProvider(input.to, input.subject, input.body);
227226
}
228227

229-
return processOrderLogic(input);
228+
// Use primary email service for regular attempts
229+
return await sendWithPrimaryProvider(input.to, input.subject, input.body);
230230
}
231231
```
232232

233-
```typescript "ctx.workerConfig" ".visibilityTimeout"
234-
// Flow handler - access worker configuration
235-
.step({ slug: 'api_call' }, async (input, ctx) => {
236-
// Use worker's visibility timeout to set safe API timeout
237-
const safeTimeout = (ctx.workerConfig.visibilityTimeout - 2) * 1000; // 2s buffer
238-
239-
console.log(`Using ${safeTimeout}ms timeout based on worker visibility timeout`);
240-
241-
const response = await fetch(input.url, {
242-
signal: AbortSignal.timeout(safeTimeout)
243-
});
244-
245-
return await response.json();
246-
})
247-
```
248233

249234
<Aside type="note">
250235
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.

pkgs/website/src/content/docs/getting-started/update-pgflow.mdx

Lines changed: 9 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -13,12 +13,12 @@ import { Aside, Steps } from "@astrojs/starlight/components";
1313
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.
1414

1515
<Aside type="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.
1717
</Aside>
1818

1919
## What needs to be updated?
2020

21-
When updating pgflow, you need to update two types of packages:
21+
When updating pgflow, you need to update:
2222

2323
1. **npm packages** - CLI, core libraries, client, and DSL packages
2424
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:
3131
Update all pgflow npm packages to the latest version:
3232

3333
```bash frame="none"
34-
npm update @pgflow/cli @pgflow/core @pgflow/client @pgflow/dsl @pgflow/example-flows
34+
npm update @pgflow/client # or @pgflow/dsl, @pgflow/core etc.
3535
```
3636

3737
Or if using yarn:
3838

3939
```bash frame="none"
40-
yarn upgrade @pgflow/cli @pgflow/core @pgflow/client @pgflow/dsl @pgflow/example-flows
40+
yarn upgrade @pgflow/client # or @pgflow/dsl, @pgflow/core etc.
4141
```
4242

4343
Or if using pnpm:
4444

4545
```bash frame="none"
46-
pnpm update @pgflow/cli @pgflow/core @pgflow/client @pgflow/dsl @pgflow/example-flows
46+
pnpm update @pgflow/client # or @pgflow/dsl, @pgflow/core etc.
4747
```
4848

4949
### 2. Update Edge Worker (JSR package)
@@ -52,10 +52,10 @@ Update the Edge Worker package in your JSR imports. In your Edge Function files,
5252

5353
```typescript
5454
// Before
55-
import { EdgeWorkerWithPgflow } from "jsr:@pgflow/edge-worker@^0.5.0";
55+
import { EdgeWorker } from "jsr:@pgflow/edge-worker@^0.5.0";
5656

5757
// After (replace with latest version)
58-
import { EdgeWorkerWithPgflow } from "jsr:@pgflow/edge-worker@^0.6.0";
58+
import { EdgeWorker } from "jsr:@pgflow/edge-worker@^0.6.0";
5959
```
6060

6161
### 3. Run pgflow install to update migrations
@@ -98,7 +98,7 @@ npx supabase migrations up
9898
pgflow uses a simple but effective migration system to ensure migrations are applied correctly:
9999

100100
<Aside type="note" title="How Migration Prefixing Works">
101-
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.
102102

103103
For example, a pgflow migration `20250429164909_pgflow_initial.sql` might be installed as `20250430000010_20250429164909_pgflow_initial.sql` in your project.
104104
</Aside>
@@ -200,4 +200,4 @@ For production updates, follow a more careful approach:
200200
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.
201201
</Aside>
202202

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!
Lines changed: 50 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,50 @@
1+
---
2+
draft: false
3+
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'
16+
image: '../../../assets/cover-images/pgflow-0-6-1-worker-config-in-handler-context.png'
17+
---
18+
19+
import { Aside } from "@astrojs/starlight/components";
20+
21+
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.
26+
27+
```typescript
28+
async function sendEmail(input, context) {
29+
const isLastAttempt = context.rawMessage.read_ct >= context.workerConfig.retry.limit;
30+
31+
if (isLastAttempt) {
32+
// Use fallback email service on final attempt
33+
return await sendWithFallbackProvider(input.to, input.subject, input.body);
34+
}
35+
36+
// Use primary email service for regular attempts
37+
return await sendWithPrimaryProvider(input.to, input.subject, input.body);
38+
}
39+
```
40+
41+
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

Comments
 (0)