feat(workflow-block): added redeploy action to workflow header for workflow block

[waleedlatif1]

Summary

• added redeploy action to workflow header for workflow block

Type of Change

• New feature

Testing

Tested manually.

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Preview	Comments	Updated (UTC)
docs	Skipped			Nov 10, 2025 11:51pm

[greptile-apps]

Greptile Overview

Greptile Summary

This PR adds a visual indicator when a child workflow referenced in a workflow block has been modified since its last deployment. It introduces a needsRedeploy flag that compares the workflow's updatedAt timestamp with the active deployment's createdAt timestamp. When changes are detected, the badge changes from green "deployed" to orange "redeploy" and becomes clickable to trigger redeployment.

Key changes:

• Added parallel API fetching for deployment versions and workflow metadata in use-child-deployment.ts
• Implemented timestamp comparison logic to detect when workflow changes require redeployment
• Updated UI to display orange "redeploy" badge with clickable action when redeployment is needed
• Maintains existing deployment functionality while adding improved workflow state visibility

Confidence Score: 4/5

• This PR is mostly safe to merge with minimal risk of breaking existing functionality
• The implementation is straightforward and well-structured, introducing a new feature without modifying core deployment logic. Parallel API fetching improves performance. The timestamp comparison logic is sound since both timestamps come from the database. However, the confidence is 4 (not 5) due to one consideration: the timestamp comparison doesn't account for timezone differences or clock skew, though this is unlikely to cause issues in practice since both timestamps are from the same database server
• Pay attention to use-child-deployment.ts - the timestamp comparison logic assumes database timestamps are consistent and monotonic

Important Files Changed

File Analysis

Filename	Score	Overview
apps/sim/app/workspace/[workspaceId]/w/[workflowId]/components/workflow-block/hooks/use-child-deployment.ts	4/5	Adds needsRedeploy logic by comparing workflow updatedAt with deployment createdAt timestamps, fetching both endpoints in parallel

Sequence Diagram

sequenceDiagram
participant UI as Workflow Block UI
participant Hook as useChildDeployment
participant API1 as /api/workflows/{id}/deployments
participant API2 as /api/workflows/{id}
participant DB as Database
UI->>Hook: Mount with childWorkflowId
Hook->>Hook: fetchActiveVersion(childWorkflowId)
par Parallel API Calls
Hook->>API1: GET /deployments (fetch active version)
API1->>DB: Query deployment versions
DB-->>API1: versions with createdAt
API1-->>Hook: {versions: [{version, isActive, createdAt}]}
and
Hook->>API2: GET /workflow (fetch metadata)
API2->>DB: Query workflow
DB-->>API2: workflow with updatedAt
API2-->>Hook: {data: {updatedAt}}
end
Hook->>Hook: Compare timestamps:<br/>needsRedeploy = workflow.updatedAt > deployment.createdAt
Hook-->>UI: Return {isDeployed, needsRedeploy, activeVersion}
alt needsRedeploy is true
UI->>UI: Show orange "redeploy" badge
Note over UI: Badge is clickable
UI->>UI: User clicks badge
UI->>API2: POST /api/workflows/{id}/deploy
API2->>DB: Create new deployment version
DB-->>API2: New deployment with new createdAt
API2-->>UI: Deployment success
UI->>Hook: refetchDeployment()
Hook->>Hook: Increment refetchTrigger
Note over Hook,API2: Repeat fetch cycle
end

Loading

[greptile-apps]

_{3 files reviewed, no comments}

_{Edit Code Review Agent Settings | Greptile}

[waleedlatif1]

• This PR is mostly safe to merge with minimal risk of breaking existing functionality
• The implementation is straightforward and well-structured, introducing a new feature without modifying core deployment logic. Parallel API fetching improves performance. The timestamp comparison logic is sound since both timestamps come from the database. However, the confidence is 4 (not 5) due to one consideration: the timestamp comparison doesn't account for timezone differences or clock skew, though this is unlikely to cause issues in practice since both timestamps are from the same database server
• Pay attention to use-child-deployment.ts - the timestamp comparison logic assumes database timestamps are consistent and monotonic

The timestamp comparison is safe because deployWorkflow explicitly does not update
workflow.updatedAt (only sets isDeployed and deployedAt), while
saveWorkflowToNormalizedTables always updates updatedAt on any change. This means
updatedAt > deploymentCreatedAt reliably indicates workflow changes occurred after the
last deployment, with no risk of false positives