[8Keep]

After a BufferObject has been uploaded, deleting or resetting its native object leaves it marked clean. Reusing it then skips the upload even though its GPU allocation no longer exists. The retained CPU data is never restored.

For an already uploaded buffer, the failing sequence is:

renderer.deleteBuffer(buffer);
renderer.setUniformBufferObject(0, buffer);

Mark the buffer and all its retained regions dirty in resetObject(), so the replacement allocation receives the complete data. This preserves the existing API and does not depend on another patch.

The new regression fails on upstream and passes with this fix.

[chatgpt-codex-connector]

Codex Review Summary: ✅ Completed

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

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-11-09T13:32:46.172051Z	8703bbb	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.

[jaime-jmebot]

Hi, thanks for addressing this lifecycle bug. The change is focused and restores the important invariant that a reset buffer is considered out of date with its native allocation.

Calling setUpdateNeeded() from resetObject() is a good fit here: it marks both the buffer and every retained region dirty, so the renderer can recreate the native allocation and upload the complete retained data rather than incorrectly treating it as already synchronized. The regression test starts with clean state and verifies both levels become dirty after reset, covering the core behavior without adding API surface.

Looks good to me—thanks for including the regression test!