Fix push conflict behavior

[eweren]

Summary by CodeRabbit

• New Features

  • Enhanced conflict handling in Push: unresolved conflicts now display in a warning banner instead of blocking the entire operation, showing specific item details (namespace, name, language) that couldn't be processed.

• Bug Fixes

  • Success count now accurately reflects only successfully updated keys, excluding conflicting items.

[coderabbitai]

Walkthrough

The Push view now tracks and displays unresolved translation conflicts. When the update mutation completes, unresolved conflicts from the API response are stored and displayed in a warning banner, with the success count adjusted to exclude conflicting keys.

Changes

Cohort / File(s)	Summary
Conflict Display Logic src/ui/views/Push/Push.tsx	Added unresolvedConflicts state to track SimpleImportConflictResult[]. Modified mutation call to pass errorOnUnresolvedConflict: false and capture result. Updated success count to exclude unresolved conflicts and added conditional warning banner displaying conflicting items by namespace, name, and language.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

Poem

🐰 Conflicts now peek through the banner's care,
With namespaces, names, and languages fair,
We count what succeeds, and show what stayed back,
A gentle alert on the push-update track. 🌿✨

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'Fix push conflict behavior' accurately describes the main change in the PR, which adds conflict tracking and display functionality to the push operation.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix-push-conflict-behavior

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

src/ui/views/Push/Push.tsx (1)

365-437: ⚠️ Potential issue | 🟠 Major

Conflicted keys are still marked as locally connected with their new value.

After the mutation returns unresolved conflicts, connectNodes() (line 434) is called unconditionally, which writes newValue onto every matching node and sets connected: true. For keys that appear in unresolvedConflicts the server did not apply the new translation (it kept the protected/reviewed/disabled value), yet the plugin now records the new value as the node's translation. On the next push/diff, getPushChanges will compare the stored new value against the server's unchanged value and either flag it as a fresh change again or, worse, treat it as already-pushed — effectively hiding the unresolved conflict from the user and causing persistent drift between Figma and Tolgee.

Filter out conflicted (key, ns, language) tuples from the set passed to connectNodes/setNodesDataMutation, e.g. keep those nodes' previous translation and connected state so the diff continues to surface them.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/ui/views/Push/Push.tsx` around lines 365 - 437, The code calls
connectNodes() unconditionally after a push, causing nodes for keys listed in
updateResult.unresolvedConflicts to be marked connected and updated with the
newValue even though the server rejected those changes; fix by filtering out
conflicted (key, ns, language) tuples before updating node state: build a Set
from updateResult?.unresolvedConflicts (use the same key/ns/lang shape the
server returns), then when calling connectNodes or setNodesDataMutation (the
functions that apply newValue/connected flags to nodes), exclude any node whose
(key, ns, language) is in that Set so those nodes retain their previous
translation and connected state and will still appear in subsequent diffs.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Outside diff comments:
In `@src/ui/views/Push/Push.tsx`:
- Around line 365-437: The code calls connectNodes() unconditionally after a
push, causing nodes for keys listed in updateResult.unresolvedConflicts to be
marked connected and updated with the newValue even though the server rejected
those changes; fix by filtering out conflicted (key, ns, language) tuples before
updating node state: build a Set from updateResult?.unresolvedConflicts (use the
same key/ns/lang shape the server returns), then when calling connectNodes or
setNodesDataMutation (the functions that apply newValue/connected flags to
nodes), exclude any node whose (key, ns, language) is in that Set so those nodes
retain their previous translation and connected state and will still appear in
subsequent diffs.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 89a9239b-fd0a-45b2-a037-cddf0c2bc4f0

📥 Commits

Reviewing files that changed from the base of the PR and between 3c5d209 and 8fb79f9.

📒 Files selected for processing (1)

• src/ui/views/Push/Push.tsx