chore(main): release 1.593.0

[rubenfiszel]

🤖 I have created a release beep boop

1.593.0 (2025-12-17)

Features

• ai: support IAM auth for bedrock provider (#7379) (8c55f61)
• backend: stop schedules and cancel jobs when archiving a workspace (#7377) (ebc82db)
• data table schemas (#7353) (75fdc2c)
• http triggers scopes (#7385) (b4eb7c6)
• internal: runnable settings (#7298) (fe56191)
• workspace forks merge UI (#7333) (9d06c15)

Bug Fixes

• add history directly viewable in folder/group viewer (#7365) (b3603d8)
• add history to raw app builder (#7362) (431074d)
• aiagent: fix gemini-3.0 usage (#7382) (f64d918)
• aichat: fix for azure responses api not available in some region (#7387) (e7719d2)
• backend: better trigger listening logs (#7392) (3ba361a)
• frontend: http/email triggers UI nits (#7378) (75e1e90)
• mcp: fix unresovled schema (#7383) (1b86a39)
• propagate canceled_by in flows (#7396) (0454f39)
• rawapp: make popup work with runnables (2f5fdd6)
• rawapp: schema for openai (#7364) (37394d6)
• SCIM 2.0 RFC compliance + displayName support (#7380) (6ffb80d)

---

This PR was generated with Release Please. See documentation.

[claude]

Claude finished @rubenfiszel's task in 3m 10s —— View job

---

Code Review: Release 1.593.0 - Workspace Forks Merge UI

This release PR contains version bumps for the workspace forks merge UI feature. I've reviewed both the release changes and the underlying feature implementation from PR #7333.

---

Release PR Review

✅ Release Artifacts

• CHANGELOG.md: Properly formatted with version 1.593.0 and feature reference
• version.txt: Correctly bumped from 1.592.1 to 1.593.0
• Release notes: Clear and concise

The release automation is working correctly.

---

Feature Implementation Review (PR #7333)

I've conducted a comprehensive review of the workspace forks merge UI feature. Here are my findings:

🎯 Overview

This feature adds a sophisticated UI for comparing and synchronizing forked workspaces, including:

• Backend workspace comparison API
• Frontend comparison drawer and banner
• Bidirectional deployment capabilities
• Conflict detection
• Permissions-aware visibility filtering

---

✅ Strengths

1. Comprehensive Comparison Logic: The backend implements thorough comparison for all major resource types (scripts, flows, apps, resources, variables)

2. Performance Optimization: Uses caching via workspace_diff table to avoid repeated comparisons

3. Permissions Awareness: The filter_visible_diffs function correctly filters items based on user visibility

4. Migration Strategy: Gracefully handles pre-existing workspaces via skip_workspace_diff_tally table

5. Good UX: The banner and comparison UI provide clear visibility into fork status

---

⚠️ Issues Found

🔴 High Priority - Security/Correctness

1. Missing Authorization Check (CRITICAL)

   • Location: backend/windmill-api/src/workspaces.rs:4106
   • Issue: The compare_workspaces function has a commented-out authorization check:

   // require_admin(authed.is_admin, &authed.username)?;

   • Risk: Any authenticated user can compare any two workspaces, potentially exposing information about workspaces they shouldn't have access to
   • Recommendation: Either implement proper authorization or document why it's intentionally open

2. Inconsistent Permission Model

   • Location: backend/windmill-api/src/workspaces.rs - filter_visible_diffs
   • Issue: The function filters items based on visibility but the comparison endpoint itself doesn't verify the user has access to both workspaces
   • Recommendation: Add workspace membership validation before comparison

3. Secret Exposure Risk

   • Location: frontend/src/lib/components/CompareWorkspaces.svelte:449
   • Issue: Variables are fetched with decryptSecret: true during deployment

   const variable = await VariableService.getVariable({
       workspace: workspaceFrom,
       path: path,
       decryptSecret: true
   })

   • Risk: Secrets are decrypted and sent to the client, then re-encrypted for deployment
   • Recommendation: Implement server-side deployment to avoid exposing decrypted secrets to the browser

🟡 Medium Priority - Performance

4. N+1 Query Pattern

   • Location: backend/windmill-api/src/workspaces.rs:4141-4174
   • Issue: The comparison loop fetches items one by one for each diff

   for item in diff_items {
       let item_comparison = match item.kind.as_str() {
           "script" => Some(compare_two_scripts(&db, ...).await?),
           // ... more individual queries
       }
   }

   • Impact: For a fork with 100 changed items, this could result in 200+ database queries
   • Recommendation: Batch fetch all items of each type, then compare in memory

5. Large Payload for Deep Comparisons

   • Location: Frontend comparison logic
   • Issue: Entire resource values (scripts, flows, apps) are fetched for diff viewing
   • Recommendation: Consider implementing server-side diff generation or pagination

🟢 Low Priority - Code Quality

6. Magic String "wm-fork-" Prefix

   • Location: frontend/src/lib/components/ForkWorkspaceBanner.svelte:14

   let isFork = $derived($workspaceStore?.startsWith('wm-fork-') ?? false)

   • Recommendation: Extract to a constant or validate via database flag

7. Commented-Out Code

   • Location: Multiple places in CompareWorkspaces.svelte (lines 200-210, 220-224, 321-347, 369-374)
   • Recommendation: Remove dead code or document why it's preserved

8. Missing Error Handling

   • Location: backend/windmill-api/src/workspaces.rs:4170
   • Issue: Unrecognized item kinds log an error but silently skip the item

   k => {
       tracing::error!("Received unrecognized item kind `{k}`...");
       None
   }

   • Recommendation: Consider returning an error or at least incrementing a metric

9. Inconsistent NULL Handling

   • Location: App comparison at backend/windmill-api/src/workspaces.rs:4462
   • Issue: Uses COALESCE(app.draft_only, false) in query but doesn't consistently handle other nullable fields
   • Recommendation: Audit all comparison functions for consistent NULL handling

10. Frontend State Management Complexity

    • Location: CompareWorkspaces.svelte - multiple reactive dependencies
    • Issue: Complex interdependent state with $derived and $effect that could lead to unnecessary re-renders
    • Recommendation: Consider simplifying the reactive graph

🔍 Database/Schema Concerns

11. Migration Inserts All Existing Workspaces

    • Location: backend/migrations/20251113112115_merge_ui_tally_changes.up.sql:23-24

    INSERT INTO skip_workspace_diff_tally (workspace_id)
    SELECT id FROM workspace;

    • Issue: This is a one-time migration that excludes all existing workspaces from diff tracking
    • Note: This is intentional but should be clearly documented in production deployment notes

12. No Index on workspace_diff

    • Issue: The workspace_diff table has no explicit indexes beyond the primary key
    • Impact: Queries filtering by has_changes or exists_in_* may be slow
    • Recommendation: Consider adding indexes based on query patterns

---

🛡️ Security Implications

Critical: The commented-out authorization check (#1) is a significant security concern. The current implementation allows any authenticated user to:

• List differences between any two workspaces
• Potentially infer information about workspace contents through comparison metadata

High: Secret handling in the frontend (#3) exposes decrypted credentials to the browser, which violates security best practices for secret management.

---

🚀 Performance Considerations

The N+1 query pattern (#4) could cause performance issues with large workspaces. For a workspace with 500 changed items:

• Current: ~1000+ database queries
• Optimized batch approach: ~10-20 queries

Recommendation: Implement batching before this feature sees heavy production use.

---

📋 Testing Recommendations

1. Authorization: Test that users cannot compare workspaces they don't have access to
2. Permission Filtering: Verify users only see diffs for items they can access
3. Performance: Test with large forks (100+ changed items)
4. Edge Cases:
   • Forks of forks
   • Deleted items
   • Items that exist in fork but not parent
   • Conflicting changes (both ahead and behind)

---

🎨 Code Quality Suggestions

1. Extract magic constants (wm-fork- prefix)
2. Remove commented-out code
3. Add comprehensive error messages
4. Document the permission model clearly
5. Consider extracting deployment logic to a backend endpoint

---

✅ What Works Well

• Clean separation of concerns between comparison and deployment
• Good use of TypeScript types and Svelte 5 runes
• Comprehensive comparison logic covering all resource types
• Smart caching strategy with workspace_diff table
• User-friendly conflict detection and reporting

---

📝 Summary

This is a substantial feature with good architectural design, but it has critical security issues that must be addressed before production use:

1. MUST FIX: Enable authorization check or document security model
2. MUST FIX: Move secret deployment to server-side
3. SHOULD FIX: Optimize N+1 query pattern for performance
4. NICE TO HAVE: Clean up commented code and add indexes

The release PR itself is fine, but I recommend addressing the security concerns in the underlying feature implementation as soon as possible.

---

🧪 Reproduction Instructions for Testers

To test the workspace forks merge UI feature, navigate to a forked workspace in the Windmill application. The workspace ID should start with "wm-fork-" and have a parent workspace configured. Upon entering any page within the forked workspace, a blue banner will appear at the top displaying the fork relationship with the parent workspace. This banner shows statistics about changes that are ahead (modifications made in the fork) and behind (updates from the parent not yet merged), broken down by resource type including scripts, flows, apps, resources, and variables. If there are any conflicts where items have changes in both directions, an orange warning indicator displays the conflict count. Click the "Review & Deploy Changes" or "Review & Update fork" button to open a detailed comparison drawer showing a side-by-side view of all differences with the ability to select individual items for deployment in either direction (fork to parent or parent to fork). Test deploying changes from the fork back to the parent workspace, updating the fork with parent changes, and handling conflict scenarios where the same item has been modified in both workspaces.

---

[cloudflare-workers-and-pages]

Deploying windmill with    Cloudflare Pages

Latest commit:	5b482a2
Status:	✅  Deploy successful!
Preview URL:	https://f34a6de1.windmill.pages.dev
Branch Preview URL:	https://release-please--branches--ma.windmill.pages.dev

View logs