Skip to content

Fix/issue 478/fetch loop and resolution order - #486

Open
goodguyry wants to merge 4 commits into
developfrom
fix/issue-478/fetch-loop-and-resolution-order
Open

goodguyry wants to merge 4 commits into
developfrom
fix/issue-478/fetch-loop-and-resolution-order

Conversation

@goodguyry

@goodguyry goodguyry commented Oct 5, 2026 •

Copy link
Copy Markdown
Member

Summary

Fixes two issues that followed the #478 fix.

  • Out-of-order validation responses. The effect started an apiFetch on every run, and whichever response returns last is used. This meant validPosts could contain pins that were no longer set and mainDedupe could drop a valid pin. The effect now sets a superseded flag in its cleanup and bails after the await, so only the latest run can update attributes.
  • Redundant writes and a self-feeding loop. setAttributes({ validPosts }) wrote a fresh array on every validation, and because the block editor compares attributes by identity, each write counted as a change. The mainDedupe() call that followed caused the effect to be re-entered, which fetched again. The result is several extra attribute writes and re-renders per pin. The setAttributes call and its dedupe pass are now skipped when validation returns what is already stored (isShallowEqual).

Tested on WordPress 6.8.2, 6.9, 7.0 and 7.1.2 installs.

goodguyry and others added 4 commits October 2, 2026 16:25
Pinning showed new post → old post → new post. An older validation response was landing after a newer one and overwriting `validPosts`, which made `mainDedupe` drop the current pin
A permanent self-feeding loop: ~1 REST request/second forever, with no editor interaction, because every write was a fresh array that re-entered the effect
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant