fix(change-detection): move change detection logic to client-side to prevent unnecessary API calls, consolidate utils

[waleedlatif1]

Summary

• move change detection logic to client-side to prevent unnecessary API calls
• consolidate utils
• added tests

Type of Change

• Bug fix

Testing

Tested manually, added tests

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	Review	Updated (UTC)
docs	Skipped		Dec 25, 2025 1:01am

[greptile-apps]

Greptile Summary

Refactored workflow change detection from server-side API calls to client-side computation, eliminating unnecessary network requests and improving performance.

Key Changes:

• Created new lib/workflows/comparison module with hasWorkflowChanged() function and normalization utilities
• Refactored useChangeDetection hook to compute changes locally using Zustand store subscriptions instead of polling the status API
• Consolidated duplicate normalization logic from SnapshotService into shared utilities
• Added 2600+ lines of comprehensive test coverage for comparison and normalization logic
• Updated API routes to import from the new comparison module
• Minor fix: Added file block type to tool input filter exclusion

Benefits:

• Reduced API calls - no more polling /api/workflows/[id]/status for change detection
• Improved UI responsiveness with 300ms debouncing instead of 500ms+ network latency
• Better code organization with shared, tested utilities
• Eliminated operation queue dependency in the hook

Confidence Score: 5/5

• This PR is safe to merge with minimal risk
• Well-architected refactoring with comprehensive test coverage (2600+ lines), clear separation of concerns, and no breaking changes to existing functionality. The change detection logic is properly extracted, shared utilities are well-tested, and the client-side implementation correctly reconstructs workflow state from stores.
• No files require special attention

Important Files Changed

Filename	Overview
apps/sim/lib/workflows/comparison/compare.ts	New file implementing client-side workflow comparison logic - extracts comparison from API endpoints
apps/sim/lib/workflows/comparison/normalize.ts	Shared normalization utilities for workflow state comparison - well-structured and tested
apps/sim/app/workspace/[workspaceId]/w/[workflowId]/components/panel/components/deploy/hooks/use-change-detection.ts	Refactored to use client-side comparison - eliminates API calls and operation queue dependencies
apps/sim/lib/logs/execution/snapshot/service.ts	Refactored to use shared normalization utils - reduces code duplication

Sequence Diagram

sequenceDiagram
    participant User
    participant DeployPanel as Deploy Panel UI
    participant Hook as useChangeDetection Hook
    participant Store as Zustand Stores
    participant Compare as hasWorkflowChanged
    participant API as Status/Deploy API

    Note over User,API: BEFORE: API-based change detection
    User->>DeployPanel: View deployment status
    DeployPanel->>Hook: Initialize (old)
    Hook->>Store: Subscribe to workflow changes
    Hook->>API: POST /api/workflows/[id]/status
    API->>API: Load from normalized tables
    API->>Compare: hasWorkflowChanged()
    API-->>Hook: { needsRedeployment: true/false }
    Hook-->>DeployPanel: Show redeployment badge

    Note over User,API: AFTER: Client-side change detection
    User->>DeployPanel: View deployment status
    DeployPanel->>Hook: Initialize (new)
    Hook->>Store: Subscribe to blocks, edges, loops, parallels
    Hook->>Hook: Build currentState with subBlocks
    Hook->>Compare: hasWorkflowChanged(current, deployed)
    Compare->>Compare: Normalize & compare edges, blocks, loops, parallels
    Compare-->>Hook: true/false
    Hook-->>DeployPanel: Show redeployment badge (no API call)

    Note over API: API still uses hasWorkflowChanged for server-side checks
    DeployPanel->>API: POST /api/workflows/[id]/deploy
    API->>Compare: hasWorkflowChanged()
    API-->>DeployPanel: Deployment result

Loading

[greptile-apps]

Additional Comments (1)

1. apps/sim/app/api/workflows/[id]/status/route.ts, line 39 (link)

   logic: Inconsistent API response: isPublished field is only included in the early return case but missing from the main response on line 69-73

   Should isPublished be included in both response objects for API consistency?

_{10 files reviewed, 2 comments}

_{Edit Code Review Agent Settings | Greptile}

[waleedlatif1]

@greptile