fix: skip re-uploading unchanged attachments to avoid Confluence rollback error

[pilat]

Why

Re-syncing a page that contains a Mermaid diagram or a local image — without changing those assets — fails on the attachment step, and the failure is silent and misleading.

Both Mermaid diagrams and local images are named after an md5 hash of their content (mermaid-<hash>.png, <basename>-<hash>.<ext>). On a re-sync the page body is written first (so the page looks correct), then the attachment step finds the asset already present under the same name and re-uploads byte-for-byte identical content.

Confluence Cloud rejects that no-op update with UnexpectedRollbackException: marked as rollback-only. The client turns the non-OK response into an error, the whole file is treated as failed, and it disappears from the run summary — so you get a confusing "0 updated" even though the body was actually saved. First-time sync worked because the asset didn't exist yet (a fresh upload, not an update).

What

Since the attachment name embeds a content hash, a name match guarantees the bytes are already identical — there is nothing to update. So the upload step now skips any attachment that already exists instead of re-uploading it. This makes re-syncs idempotent and removes the rollback error.

The now-unused update-attachment client method (its only caller was the buggy path, and it wasn't part of the documented client surface) is removed rather than left as a footgun.

Tests

Two regression tests around an idempotent re-sync with a local image:

• An attachment that already exists under its content-hashed name is not re-uploaded, and the file is still reported as updated (not silently dropped).
• An attachment that is not yet present is still uploaded as before.

[coderabbitai]

Warning

Review limit reached

@pilat, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 4 minutes and 3 seconds. Learn how PR review limits work.

Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file).

⌛ How to resolve this issue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits.

🚦 How do rate limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan refill rate.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, the refill rate gradually slows as usage increases. The highest same-day bursts are limited more strictly.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: fdce93da-f8d3-465d-bf70-06555a7017e4

📥 Commits

Reviewing files that changed from the base of the PR and between 5270305 and 4cc20e3.

📒 Files selected for processing (3)

• src/confluence/client.ts
• src/sync.ts
• test/sync.test.ts

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/idempotent-attachment-resync

---

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.}