bug: Stale workspace_diff rows cause false "changes not visible to your user" blocking fork merges #8327
Description
Describe the bug
When comparing a fork workspace against its source, the UI shows "This fork has changes not visible to your user" and blocks merging, even when the user is an admin with full visibility.
The issue seems to be caused by stale rows in the workspace_diff table. If an item has changes recorded and is then renamed, the stale entry appears to persist indefinitely. It looks like this line skips re-validation for items that already have has_changes = true:
It seems like when filter_visible_diffs later tries to query these items, they no longer exist at the old path, so they get filtered from visible_diffs but may still be counted in confirmed_diffs, causing the visibility totals to mismatch and blocking the merge.
Manually deleting the stale rows from workspace_diff resolved the issue in our case.
In our original encounter, we had stale rows for both a renamed script and a resource that no longer existed. We were only able to reproduce reliably with the rename scenario for a script, but the resource case may follow a similar pattern.
To reproduce
- Fork a workspace
- Make a change in the fork (e.g., edit a script and save)
- Trigger a compare by visiting the fork comparison UI — this seems to set
has_changes = trueon the diff row - Rename/move that same script in the fork
- Visit the fork comparison UI again
- The UI blocks the merge with "This fork has changes not visible to your user"
The key seems to be that the compare in step 3 must happen before the rename in step 4, so the workspace_diff row gets persisted with the old path.
Expected behavior
Items that have been renamed or moved since the diff was recorded should not block the merge.
Screenshots
No response
Browser information
No response
Application version
EE v1.654.0
Additional Context
No response