edge-worker

pgflow 0.6.1: Worker Configuration in Handler Context

Sep 5, 2025 - 1 min read

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

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

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

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

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

-- Deprecate old workers before starting new ones
UPDATE pgflow.workers
SET 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

The context object is now cleaner and more consistent:

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

Update context usage: context.serviceSupabase → context.supabase
Remove any context.anonSupabase usage
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

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

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

// Before: Global resources that complicated testing and lifecycle management
import { sql } from '../db.js';
import { supabase } from '../supabase-client.js';

// After: Clean dependency injection via context
async 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

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

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

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

Migration

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

// Old handlers work fine
async function handler(input) { return { ok: true }; }

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

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