Skip to main content
← Back to list
01Issue
BugShippedSwamp CLI
Assigneesstack72

Relationships

#521 Workflow engine resolves extension methods against base type, ignoring extension-registered methods

Opened by webframp · 6/1/2026· Shipped 6/1/2026

Summary

When a workflow step calls a method provided by a local extension (not the base type), the workflow engine intermittently resolves the method against the base type only — reporting "Unknown method" — even though the same method works when called directly via swamp model method run. This indicates a race condition between bundle registration/loading and workflow method validation.

Environment

  • swamp version: 20260530.005533.0-sha.1c117111
  • OS: Linux (WSL2)
  • Base type: @webframp/gitlab (6 original methods)
  • Extension: local model extending the base type with ~45 additional methods

Steps to Reproduce

  1. Extend a base type with additional methods via export const extension in extensions/models/.
  2. Create a workflow YAML that calls one of the extension methods.
  3. Run the workflow. It will succeed sometimes, fail other times.
  4. Under concurrent load (multiple workflows + model method calls in parallel), the failure rate increases.

Observed Behavior

ERR workflow·run·daily-summary·overview·list-todos Step failed:
  "Unknown method 'list_todos' for type '@webframp/gitlab'.
   Available methods: list_projects, get_project_info, list_merge_requests,
                      list_issues, list_releases, list_pipelines"

The base type has exactly 6 methods. The extension adds ~45 more (including list_todos, list_groups, list_runners, etc.).

When the same methods are called directly:

swamp model method run <model> list_todos state=pending

They always succeed — even during the same concurrent stress test.

The error occurs:

  • Intermittently across all workflow types
  • Across independent workflow runs
  • Throughout a 70-minute parallel stress test across 3 concurrent workflow subagents
  • Never when calling methods directly via swamp model method run

The swamp summarise command also reports these as last errors, confirming persistence.

Impact

  • Workflows that depend on extension methods are unreliable — they randomly fail
  • No feedback on why the extension wasnt loaded (no bundle loading error, just "unknown method")
  • Forces users to either only use base type methods in workflows or accept random workflow failures

Root Cause Hypothesis

The workflow engine evaluates methods against the base type definition (the type as published in the registry), which knows about only the base methods. The extensions methods are registered at bundle time but the workflow engine reads the cached type definition before the extension bundle is loaded.

Direct model method calls always work because they resolve at execution time against the loaded extension bundle, not the cached type definition.

Suggested Fix

  • Workflow method validation should use the same method resolution path as swamp model method run at execution time
  • Or eagerly resolve extension bundles before workflow validation
  • Or add retry logic in the workflow engine if a method is not found on first lookup
02Bog Flow
OPENTRIAGEDIN PROGRESSSHIPPED+ 1 MOREASSIGNED+ 2 MOREREVIEW+ 3 MOREPR_MERGED+ 1 MORECONTRIBUTOR_NOTIFIED

Shipped

6/1/2026, 9:44:32 PM

Click a lifecycle step above to view its details.

03Sludge Pulse
stack72 assigned stack726/1/2026, 6:10:17 PM
Editable. Press Enter to edit.

webframp commented 6/1/2026, 6:44:44 PM

A second stress test (1 hour, 15 parallel subagents) confirms this race persists.

Results

Workflow Type Subagents Unknown Method Errors Workflow Failures
daily-summary 3 (SA7-9) 7-13 each 7-13 each
project-health-check 2 (SA10-11) 1-6 each 14-16 each
mr-triage 2 (SA10-11) (included above) (included above)

Unknown method errors occurred on:

  • list_todos — most frequent
  • list_groups — second most frequent
  • list_runners — occasional

Error rate is roughly 1-2% of all workflow runs. No single workflow type is immune — all three affected.

Additional observation

The race persists regardless of load level. SA10-11 ran at a slower cadence (8-12s between workflow runs) and still hit it, while SA7-9 (5-15s) hit it more often. This suggests it is not purely a load-dependent race but a timing window during bundle loading that can be triggered even at low concurrency.

Method calls vs workflows

All direct swamp model method run calls to the same methods (list_todos, list_groups, list_runners) succeeded 100% of the time across all subagents throughout the test — hundreds of calls with zero "unknown method" errors. The bug is exclusively in the workflow evaluation path.

swamp summarise reports these errors in its "last error" section, persisting them beyond the individual workflow run. This means stale "unknown method" errors remain visible in aggregate views long after the transient condition has cleared.

webframp commented 6/1/2026, 9:02:33 PM

Retested on version 20260601.163824.0-sha.c2872a24 (15 subagents, 1 hour). Results are essentially unchanged:

Workflow subagents Unknown method errors Workflow failures
SA7-9 (daily-summary, 3 agents) 8-12 each 7-10 each
SA10-11 (health-check + mr-triage, 2 agents) 2 each 13-18 each

Same 1-2% failure rate on workflow runs. Direct model method run calls to list_todos, list_groups, list_runners continue to succeed 100%.

swamp summarise still shows:

  • daily-summary: "Unknown method 'list_todos'"
  • project-health-check: "Unknown method 'list_groups'"

Swamp version 163824.0 does not appear to contain a fix for this issue.

stack72 commented 6/1/2026, 9:44:39 PM

Thanks @webframp for reporting this! The fix has been merged and a release is on its way. We appreciate your contribution to swamp.

Sign in to post a ripple.