Fix History Panel bugs and add version mismatch warning in collaborative editor

[lmac-1]

Description

This PR improves the history panel experience in the collaborative editor by fixing critical bugs that prevented navigation to the "view all history" page and adding a version mismatch warning to prevent user confusion.

Closes #3814 and point 1 of #3940

History page 500 error when navigating from collaborative editor

• Frontend: Fix workflow ID extraction in MiniHistory - was taking "collaborate" instead of the actual UUID from /w/:id/collaborate URLs
• Backend: Handle nil case in humanize_workflow when workflow not found
• Impact: "View History" button now works from collaborative editor

Feature: Version mismatch warning banner

Shows a warning when viewing latest workflow but selected run was executed on an older version. Prevents confusion when workflow structure has changed since the run executed. Appears when:

• Run selected AND viewing "latest" AND versions differ

Example message:

⚠️ This run was executed on version 66, but you're viewing version 67. Steps shown may not match the current workflow structure.

Testing

• All existing tests passing
• 8 new unit tests for version mismatch detection hook

Validation steps

Version mismatch warning:
You have two choices

1. Pick an existing workflow where the structure has changed over time in the last 20 runs
2. Make an update to an existing workflow and click Save

Once you have a workflow where the latest version is different to previous version:

1. Select an old run while viewing "latest" -> Banner appears
2. Switch to matching snapshot version -> Banner disappears
3. Deselect run -> Banner disappears

Bug fix:

1. Open workflow in collaborative editor -> Click the little icon next to "View full history" (marked in screenshot above)
2. Verify history page loads AND that it has the correct content (it previously crashed)

Additional notes for the reviewer

I tried to make the banner look similar to existing banner in LiveView using Tailwind colours.

AI Usage

Please disclose how you've used AI in this work (it's cool, we just want to know!):

• Code generation (copilot but not intellisense)
• Learning or fact checking
• Strategy / design
• Optimisation / refactoring
• Translation / spellchecking / doc gen
• Other
• I have not used AI

You can read more details in our Responsible AI Policy

Pre-submission checklist

• I have performed a self-review of my code.
• I have implemented and tested all related authorization policies. (e.g., :owner, :admin, :editor, :viewer)
• I have updated the changelog.
• I have ticked a box in "AI usage" in this PR

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 88.66%. Comparing base (7ef09a6) to head (ead8c72).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3941      +/-   ##
==========================================
+ Coverage   88.64%   88.66%   +0.02%     
==========================================
  Files         422      422              
  Lines       18913    18913              
==========================================
+ Hits        16766    16770       +4     
+ Misses       2147     2143       -4     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[lmac-1]

This one is ready for review @stuartc @taylordowns2000 @theroinaochieng ☺️. Probably one for Monday now.

[lmac-1]

@stuartc I decided to put the version mismatch stuff in a hook to not overcomplicate components. There's also a test to test the logic of the hook.

[taylordowns2000]

the history navigation link works perfectly, but I'm seeing two bugs in the version matching stuff:

1. when going to an old run, it should take you to that version—not keep you on latest and show the mismatch banner. (play around with this feature on the legacy canvas to see how it should work.)
2. i'm seeing all the nodes collapse into the middle.

Both of these show up in the video here: https://www.loom.com/share/5fd45ef0e7bf4911a56bf511c03729c4

[elias-ba]

Hey @lmac-1 this is looking great to me from a code point of view. I alkso clicked tested and it looks great. I will leave the UI approvals to Taylor. @taylordowns2000 just wanna flag that the nodes collapsing issue might be out of scope of this work. It has became rare now but it's still happening from time to time in the app on main. I think we may need to have a proper issue for it and do deep diagnostic for it. I do think that it's deeply related to nodes positionning and layout algorithm.

[lmac-1]

Hey @taylordowns2000 thanks for the Loom, yes that makes sense, will take a look! I didn't realise that the version should update at the top.

And for the nodes collapsing, I have also been seeing it a bit in other bits of dev work that I'm working on in other branches / main, but not sure what are the exact steps to replicate. Seems to be a bit random. As @elias-ba suggested, it might be worth diving deeper into that in a separate issue. Will try to keep an eye out for it though to see what is causing it.

[lmac-1]

I think I've fixed the node position bug... but would appreciate some help in understanding how 😅

I was able to consistently reproduce the collapsing nodes issue across multiple branches using these steps:

1. Select a run from the history panel with a "Failed" status.
2. Refresh the page.
3. The nodes will appear collapsed at position (0,0).
4. If you then select a different run and return to the failed run, the nodes display correctly.

I looked into this with Claude, and it suggested the fix I implemented here in this branch in adc80d9. The fix works, but I don't fully understand why: The change suppresses the "could not auto-calculate position" warnings when the positions cache is empty on initial render (which is expected before layout runs). But removing these console.warn() calls also fixes the visual issue where nodes appear collapsed - not just the console spam. My theory is that the console operations during the render cycle were causing some kind of timing/performance issue that prevented the layout system from completing before React painted the nodes. But I'm not confident in this explanation. @elias-ba - do you have insight into why removing these warnings would fix the visual positioning issue? Is there something about how ReactFlow or the layout system interacts with synchronous operations during render that I'm missing?

@taylordowns2000 can you retest where you saw the error? It should happen when you have a run selected with a non-successful status and then refresh the page.

[lmac-1]

Okay @taylordowns2000, I think I have fixed everything you mentioned:

1. Clicking on runs now automatically updates the version in the header
2. If you then manually select "Latest", the warning appears as expected

I also improved the warning logic so it appears whenever you're viewing a different version than the run's version, not just when viewing "latest". For example:

1. You select a run that was executed on version 4
2. The header automatically switches to v4 (no warning - versions match)
3. You manually change to "Latest" (version 5) → Warning appears: "This run was executed on version 4, but you're viewing version 5..."
   4.You manually change to version 3 → Warning still appears: "This run was executed on version 4, but you're viewing version 3..."

This gives you flexibility to compare runs against any workflow version while staying aware of mismatches.

[taylordowns2000]

Fantastic! Thanks, @lmac-1 !