docs/solutions/ui-bugs/2026-04-05-block-discussion-must-resolve-current-path-inside-the-wrapper-component.md
BlockDiscussion must resolve the current block path inside the wrapper componentApproving a block deletion could leave the next block's suggestion UI in an old state.
The data was already updated, but the block below still rendered from the old owner path until another edit happened.
BlockDiscussion resolved blockPath, comment nodes, and suggestion nodes in the outer RenderNodeWrapper closure.
That works while sibling paths stay stable. After a block above is removed, the next block shifts left in the tree, but the wrapper can keep rendering with the old captured path.
The shared discussion index was already invalidating by editor version. The stale part was the captured blockPath, not the index itself.
Move all path-derived reads into the actual React component that rerenders with editor state:
editor.api.findPath(element) inside BlockCommentContentdraftCommentNode, commentNodes, and suggestionNodes thereThat lets the existing useEditorVersion() subscription inside useBlockDiscussionItems recompute against the current block key after sibling paths shift.
These checks passed:
bun test apps/www/src/registry/ui/block-discussion.spec.tsx
bun test apps/www/src/registry/ui/block-discussion-index.spec.ts
pnpm install
pnpm turbo build --filter=./apps/www
pnpm turbo typecheck --filter=./apps/www
pnpm lint:fix
Do not capture Path-derived ownership state in the outer RenderNodeWrapper closure when sibling insertions or deletions can shift paths.
If a wrapper depends on the current location of an element, resolve that location inside the rerendering component body instead.