← Back to runs
article_flow Failed
56834b08-2774-446a-9a4e-fa1bd2220067
Progress
2/5 steps
40.0%
Duration
10.5h
Started
2026-08-19 06:36:08
Workflow
Click a node to view its output
Step States
Click a step to view its output
Completed
fetch_article
7.1s
Tasks: 1/1
Completed
convert_to_markdown
84ms
Tasks: 1/1
Running
extract_keywords
10.5h
Tasks: 0/1
(1 failed)
Failed
summarize
10.5h
Tasks: 0/1
(1 failed)
Pending
publish
-
Timeline
Step execution timing · Total: 10.5h
Completed
Running
Failed
Pending
Step: convert_to_markdown
Step selectedInput
Input comes from dependencies: fetch_article
(Click on a dependency step to see its output)
Output
Task 0
{
"char_count": 4053,
"markdown": "# pgflow 0.13.1: CLI Fix + Step Output Storage for Conditional Execution Note on 0.13.0 Version 0.13.0 was yanked from npm and JSR due to unreliable local environment detection. The key-based detection approach did not work correctly with recent Supabase CLI versions. This release (0.13.1) replaces it with a more robust URL-based detection method. pgflow 0.13.1 fixes a compatibility issue with recent Supabase CLI versions and introduces atomic step output storage for 2x faster Map chains. ## Supabase CLI Compatibility Fix If local development stopped working after a Supabase CLI update, this release fixes it. pgflow now detects local development by checking the SUPABASE_URL environment variable. When running locally, Supabase CLI sets this to http://kong:8000 (the Docker-internal API gateway). This is more reliable than the previous key-based detection, which broke when Supabase CLI transitioned to new opaque API keys. ## Step Output Storage ### What Changed Step outputs are now stored in step_states.output when a step completes, rather than being aggregated on-demand. ### How It Worked Before Previously, every time a downstream step needed its dependency’s output, pgflow ran an aggregation query: For a Map step with 500 items, this query scanned 500 rows. When another Map step depended on it with 500 tasks, that’s 500 tasks x 500 rows = 250,000 row scans. ### Performance Gains With outputs pre-stored, downstream tasks now read a single column instead of aggregating: The complexity dropped from O(N^2) to O(N) for Map-to-Map chains. ### Simpler Manual Queries Querying step outputs is now straightforward: No need to aggregate from step_tasks - the output is ready to use. ## Migration Guide This release includes a data migration that backfills step_states.output for existing completed steps. Data Migration - Test First This migration backfills data for all completed steps. Download a production database dump and test the migration locally before applying to production. The backfill is safe (only touches completed rows) but should run during low-traffic periods and with no workers running. - Test locally with production dataDownload a production backup and restore it locally to test the migration. See Restoring a downloaded backup in the Supabase docs, then run npx supabase db push to test the migration. Test locally with production data Download a production backup and restore it locally to test the migration. See Restoring a downloaded backup in the Supabase docs, then run npx supabase db push to test the migration. - Record enabled worker functionsBefore disabling, note which functions are currently enabled:SELECT function_name FROMpgflow.worker_functionsWHEREenabled= true;Save this list - you’ll need it in step 7. Record enabled worker functions Before disabling, note which functions are currently enabled: Save this list - you’ll need it in step 7. - Disable all worker functionsUPDATEpgflow.worker_functionsSETenabled= false; Disable all worker functions - Deprecate running workersUPDATEpgflow.workersSET deprecated_at =NOW()WHERE deprecated_at ISNULLAND stopped_at ISNULL; Deprecate running workers - Wait for all workers to stopSELECTCOUNT(*) FROMpgflow.workersWHERE stopped_at ISNULL;Wait until this returns 0. Wait for all workers to stop Wait until this returns 0. - Apply database migrationnpxsupabasedbpush Apply database migration - Deploy workers and re-enableDeploy your workers and re-enable only the functions that were enabled before:npxsupabasefunctionsdeployUPDATEpgflow.worker_functionsSETenabled= trueWHERE function_name IN ('worker-1', 'worker-2'); -- from step 2 Deploy workers and re-enable Deploy your workers and re-enable only the functions that were enabled before: ## Looking Ahead This change stores step outputs in a queryable location - a prerequisite for conditional execution. Future releases will use these stored outputs to evaluate conditions and skip steps dynamically. Questions or issues? Join the Discord community or open a GitHub issue. - release - performance"
}