Skip to content

Conversation

@FriederikeHanssen
Copy link
Member

No description provided.

FriederikeHanssen and others added 3 commits December 23, 2025 09:10
The workflow-monitor node had a critical design flaw preventing it from
monitoring multiple workflows simultaneously. When multiple workflow
messages arrived in quick succession, only the most recent workflow
would be monitored, causing earlier workflows to be dropped from tracking.

Root causes:
- Single shared intervalId variable - new workflows cleared previous intervals
- Captured message context in closures - new messages replaced old contexts
- clearPolling() on every input - stopped all active monitoring

Solution:
- Replace single intervalId with Map-based tracking (activeWorkflows)
- Each workflow gets independent polling with its own interval
- Preserve message context (correlationId, _context, etc.) per workflow
- Only clear polling for specific workflows when they reach terminal state
- Show workflow count in status display when monitoring multiple workflows
- If same workflowId is triggered twice, replace the old monitor

Tests added:
- Verify multiple workflows can be monitored independently
- Verify message context is preserved for each workflow separately
- Verify proper cleanup when same workflowId is re-triggered

This enables use cases like batch workflow launching where multiple
pipelines need to be monitored through completion simultaneously.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Sonnet 4.5 <[email protected]>
This commit addresses several critical issues in the concurrent workflow monitoring implementation:

- Fix memory leak: Store only essential workflow data (workspaceId, passthroughProps) instead of full message objects with potentially large payloads
- Optimize performance: Evaluate properties (workspaceId, pollInterval) once at workflow start rather than on every poll
- Improve robustness: Store local references in fetchStatus() to prevent edge cases if workflow is cleared during API calls
- Standardize error messages: Use consistent "Workflow {id}: {message}" format across all error paths
- Fix test: Update error handling test to match new error message format and prevent double-done calls

All 168 tests passing.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Sonnet 4.5 <[email protected]>
Changed from blacklist approach (excluding multiple specific properties) to
only excluding payload. This makes the function more resilient to:

- Future Node-RED properties (will automatically pass through)
- Standard Node-RED properties like topic, _msgid (now preserved)
- Custom user properties (all preserved except payload)

The output message explicitly sets workflowId and payload, so those values
are always controlled regardless of what comes through in passthrough props.

This approach is simpler, more maintainable, and prevents future issues if
Node-RED adds new internal properties.

All 168 tests passing.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Sonnet 4.5 <[email protected]>
@github-actions
Copy link

github-actions bot commented Dec 23, 2025

🐳 Docker PR Build

Status ✅ Built successfully
Commit 78454afaa910caeb654e53abc2203daa47044d61
Standard ghcr.io/seqeralabs/node-red-seqera:pr-35
Studios ghcr.io/seqeralabs/node-red-seqera-studios:pr-35

View workflow run

@FriederikeHanssen FriederikeHanssen marked this pull request as ready for review December 23, 2025 11:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants