[dezren39]

Fixes #1379. Stacked on #3194 (base branch queue/1312-1323-paste-order) — it restructures the same completion handler for #1323 ordering; this PR will be retargeted to main once #3194 merges.

Problem

When the placeholder decoration was deleted while an upload was in flight, the completion handler fell back to the captured insertPos and inserted unconditionally. If the document had shrunk past that position, insert threw RangeError and the successfully uploaded image was silently lost (on main the shared .catch also mislogs it as "Upload failed"; on #3194's restructure it became an unhandled rejection).

Fix (per triage task 1345's decided policy)

• Clamp the fallback position into the current document range (Math.min(pos, doc.content.size), floored at 0), then resolve through insertPoint so the image lands at a position where it actually fits; the placeholder-found position is still preferred as today.
• Insertion is attempted in its own try/catch: failures are logged distinctly as [image-upload] Insertion failed for … — never as an upload failure, never as an unhandled rejection — and the placeholder is still removed.

Tests

• New regression test (id(web): image upload completing after the document shrinks is silently lost — stale insert position throws, success logged as failed #1379): paste at position 25, replace the whole document with one character while the upload is in flight (placeholder deleted with the replaced range), resolve the upload → image is inserted at a valid in-range position, and no failure of either kind is logged.
• Fail-first verified: the test fails on the stacked base without this fix, with the RangeError surfacing as an unhandled error.
• Laptop: bunx vitest run src/image-upload.test.ts — 46/46 pass (including the id(web): multi-image paste/drop inserts images in upload-completion order, not clipboard order #1323 ordering tests from the base branch).

Queue task 4661.

---

^{Need help on this PR? Tag @codesmith-bot with what you need.}

[coderabbitai]

Warning

Review limit reached

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

Next included review available in 29 minutes.

Check out review usage here.

View limit details

Limit details: You’ve used the included review currently available.

Learn how review limits work.

Review configuration:

Run configuration

• Source mode: Auto
• Repository: Unavailable
• Branch: Unavailable
• File: No configuration file from this repository applied
• Commit: Unavailable
• Layers: defaults
• Review profile: CHILL
• Plan: Advanced
• Run ID: 827840b6-5a0b-4f1a-88ec-a97c2e6add11

Commits

Reviewing files that changed from the base of the PR and between 36a3347 and 2eff043.

Files selected for processing: 2

• pkgs/id/web/src/image-upload.test.ts
• pkgs/id/web/src/image-upload.ts

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

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

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-31T20:06:28.454256Z	2eff043	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[dezren39]

Salvage note (protocol §8) — duplicate PR #3202 closed in favour of this PR, which is the one bound to queue task 4661 (parked against this PR @2eff04340).

The two diffs were compared in full (not just file lists): both touch only pkgs/id/web/src/image-upload.ts and image-upload.test.ts, with the same clamp formula, the same distinct [image-upload] Insertion failed logging, and the same shrink-during-upload regression scenario. Nothing unique to salvage from #3202 — this PR is a superset: it additionally routes the clamped position through insertPoint(...) so the image lands at a position valid for a block node, and its test asserts no warning of any kind was logged. #3202's author (a second lane that had concurrently claimed task 4661) verified its own variant at 46/46 tests with ablation before the collision was detected; no code needs to move across.

— repo-worker-code, lane A