Skip to content

# context

3 posts with the tag “context”

## pgflow 0.6.1: Worker Configuration in Handler Context

Sep 5, 2025 - 1 min read
Wojciech Majewski (@jumski)
Creator and Maintainer

pgflow 0.6.1 adds `workerConfig` to the handler execution context, enabling intelligent decision-making based on worker configuration.

## Worker Configuration in Context

Section titled “Worker Configuration in Context”

Handlers now have access to the complete worker configuration through `context.workerConfig` (#200). This enables smarter handlers that can adapt their behavior based on retry limits, concurrency settings, timeouts, and other worker parameters.

    async function sendEmail(input, context) {  const isLastAttempt = context.rawMessage.read_ct >= context.workerConfig.retry.limit;
      if (isLastAttempt) {    // Use fallback email service on final attempt    return await sendWithFallbackProvider(input.to, input.subject, input.body);  }
      // Use primary email service for regular attempts  return await sendWithPrimaryProvider(input.to, input.subject, input.body);}

See the context documentation for complete details on available configuration properties and additional examples.

## Bug Fix

Section titled “Bug Fix”

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).

## Updating to 0.6.1

Section titled “Updating to 0.6.1”

Follow our update guide for step-by-step upgrade instructions.

## pgflow 0.6.0: Worker Deprecation and Context Changes

Aug 6, 2025 - 1 min read
Wojciech Majewski (@jumski)
Creator and Maintainer

pgflow 0.6.0 introduces worker deprecation for deployments without version overlap and simplifies the context object with breaking changes.

## Worker Deprecation

Section titled “Worker Deprecation”

Deploy new workers without version overlap. Deprecated workers stop accepting new tasks while finishing current work.

    -- Deprecate old workers before starting new onesUPDATE pgflow.workersSET deprecated_at = NOW()WHERE function_name = 'your-worker-name'  AND deprecated_at IS NULL;

Workers detect deprecation within 5 seconds via heartbeat and gracefully stop polling. The deployment guide has been simplified with a single safe deployment sequence.

## Breaking Context Changes

Section titled “Breaking Context Changes”

The context object is now cleaner and more consistent:

Breaking Changes

- Removed: `context.anonSupabase`
- Renamed: `context.serviceSupabase` → `context.supabase`

Before (0.5.x):

    async function handler(input, context) {  const { data } = await context.serviceSupabase    .from('users')    .select('*');}

After (0.6.0):

    async function handler(input, context) {  const { data } = await context.supabase    .from('users')    .select('*');}

## Migration

Section titled “Migration”

1. Update context usage: `context.serviceSupabase` → `context.supabase`
2. Remove any `context.anonSupabase` usage
3. Use worker deprecation for smooth deployments

The service role client is now the primary Supabase interface, simplifying database operations in handler functions.

## pgflow 0.5.4: Context - Simplify Your Handler Functions

Jul 17, 2025 - 2 min read
Wojciech Majewski (@jumski)
Creator and Maintainer

API Change in v0.6.0

Breaking Change: Starting with pgflow v0.6.0, the context API has been simplified. The `anonSupabase` and `serviceSupabase` clients have been replaced with a single `supabase` client (initialized with service role key).

If you’re using v0.6.0 or later, replace any usage of `ctx.anonSupabase` or `ctx.serviceSupabase` with `ctx.supabase`.

Workers now pass a context object as a second parameter to all handlers, providing ready-to-use database connections, environment variables, and Supabase clients.

## The Problem We Solved

Section titled “The Problem We Solved”

Previously, handlers relied on global singletons or manual resource initialization:

    // Before: Global resources that complicated testing and lifecycle managementimport { sql } from '../db.js';import { supabase } from '../supabase-client.js';
    // After: Clean dependency injection via contextasync function processPayment(input, ctx) {  const [payment] = await ctx.sql`    SELECT * FROM payments WHERE id = ${input.paymentId}  `;  await ctx.serviceSupabase.from('audit_logs').insert({    action: 'payment_processed',    payment_id: input.paymentId  });}

## What’s in the Context

Section titled “What’s in the Context”

Core resources (always available):

- `env` - Environment variables
- `shutdownSignal` - AbortSignal for graceful shutdown
- `rawMessage` - pgmq message metadata (msg_id, read_ct, etc.)
- `stepTask` - Step execution details (flows only)

Supabase resources:

- `sql` - PostgreSQL client (postgres.js)
- `anonSupabase` - Client with anon key (respects RLS)
- `serviceSupabase` - Client with service role (bypasses RLS)

## Key Benefits

Section titled “Key Benefits”

1. Zero Configuration - No connection boilerplate
2. Managed Resources - pgflow handles pooling and lifecycle
3. Type Safety - Full TypeScript support
4. Testable - Mock only what you use:

    // Handler uses only env? Test with only env:await handler(input, { env: { API_KEY: 'test' } });

## Migration

Section titled “Migration”

Existing handlers continue to work. Add the context parameter when you need platform resources:

    // Old handlers work fineasync function handler(input) { return { ok: true }; }
    // New handlers get contextasync function handler(input, ctx) {  const data = await ctx.sql`SELECT * FROM table`;  return { ok: true, count: data.length };}

This is Just the Beginning

Context is how pgflow manages resources. Soon you’ll define your own resources (OpenAI, Stripe, Redis, helpers) and access them the same way. Start using context now to be ready.

Updated packages: `@pgflow/edge-worker` and `@pgflow/dsl`