Summary
Scenario 90 exploratory QA found that inline HTTP-triggered Workflow pipelines repeatedly log event-recorder warnings even though the request pipelines complete successfully.
The server wires an EventRecorder / EventStoreRecorder, but these inline pipeline executions have an empty Pipeline.ExecutionID, so the event recorder attempts to persist events with an empty execution ID and logs warnings like:
level=WARN source=.../module/pipeline_executor.go:79 msg="Failed to record execution event" event_type=execution.started execution_id="" error="parse execution ID \"\": invalid UUID length: 0"
Reproduction
From workflow-scenarios Scenario 90 on origin/main (fb5071c), using released admin/authz UI plugin tags:
cd scenarios/90-admin-tailnet-demo
PLUGIN_ADMIN_REPO=/Users/jon/workspace/workflow-plugin-admin/.worktrees/qa-v1.1.9 \
PLUGIN_AUTHZ_UI_REPO=/Users/jon/workspace/workflow-plugin-authz-ui/.worktrees/qa-v1.0.6 \
./seed/seed.sh
cd .build/playwright-cli-qa
BASE=http://127.0.0.1:18080 npx playwright test exploratory-admin.spec.mjs --reporter=list --workers=1
cd ../..
docker compose logs app | rg -i 'Failed to record execution event|invalid UUID length'
Observed during successful request pipelines such as list-admin-contributions and authz-capabilities.
Expected
When event recording is wired, inline HTTP-triggered pipelines should either:
- receive/generate a valid execution ID before recording events, or
- skip event recording for executions that intentionally do not participate in execution tracking.
They should not emit repeated warnings on successful request paths.
Impact
The auth/authz UI behavior itself passed exploratory QA, but runtime-launch validation log scraping flags this as a failure signature. It also makes production logs noisy and can hide real event-recording failures.
Notes
Relevant code paths found during triage:
module/pipeline_executor.go records via p.EventRecorder.RecordEvent(ctx, p.ExecutionID, ...).module/execution_tracker.go assigns ExecutionID when running through the tracker path.cmd/server/main.go wires EventRecorder / EventStoreRecorder broadly, so inline HTTP pipelines can record without a tracker-generated execution ID.
Summary
Scenario 90 exploratory QA found that inline HTTP-triggered Workflow pipelines repeatedly log event-recorder warnings even though the request pipelines complete successfully.
The server wires an EventRecorder / EventStoreRecorder, but these inline pipeline executions have an empty
Pipeline.ExecutionID, so the event recorder attempts to persist events with an empty execution ID and logs warnings like:Reproduction
From
workflow-scenariosScenario 90 onorigin/main(fb5071c), using released admin/authz UI plugin tags:Observed during successful request pipelines such as
list-admin-contributionsandauthz-capabilities.Expected
When event recording is wired, inline HTTP-triggered pipelines should either:
They should not emit repeated warnings on successful request paths.
Impact
The auth/authz UI behavior itself passed exploratory QA, but runtime-launch validation log scraping flags this as a failure signature. It also makes production logs noisy and can hide real event-recording failures.
Notes
Relevant code paths found during triage:
module/pipeline_executor.gorecords viap.EventRecorder.RecordEvent(ctx, p.ExecutionID, ...).module/execution_tracker.goassignsExecutionIDwhen running through the tracker path.cmd/server/main.gowiresEventRecorder/EventStoreRecorderbroadly, so inline HTTP pipelines can record without a tracker-generated execution ID.