#race condition

I don't think it has anything to do with error about the require field. Instead I think is actually because when Page is already checked in "review x changes" then the client doesn't request the update list after there are new changes. It just happens it was discovered because when you get the error about the require property the UI leaves the page checked in "review X changes"

It should be reproducible via

1. Open XB with no pending changes
2. create a new page
3. make a change to the title
4. wait till "review 1 change" to show
5. click "review 1 change"
6. select the new page in the "unpublished changes" list but do not publish
7. close the "unpublished changes"
8. make another change to the title
9. wait a few seconds, to ensure this not a problem with a race condition
10. click "review 1 change",
11. observe that page is still selected
12. wait a few seconds, to ensure this not a problem with a race condition
13. click publish
14. you should get the error

It appears that if you have something selected in the "unpublished changes" list then even when you close the list and make a new change the client does not request the pending changes from /xb/api/v0/auto-saves/pending

If you do the same steps but do not select the page for publishing until after you have viewed and closed the "unpublished changes" list 1x time and only select it right before publishing you will not get the problem

There may be other race conditions still but I think the problem described is actually a race condition it doesn't matter how long you wait between the steps you will still run into the problem.

I think this needs a front-end fix

Might have been introduced in 📌 Create UI for selective publishing of changes Active because that is where the ability to select individual items to publish was added

Assigining to @mred9 because I think he does most of the front-end work there

wim leers → credited mayur-sose → .

Crediting Mayur for finding this.

Assigning to Auto-save maintainer @tedbow to investigate deeper, and to decide whether this requires only front-end changes or not.

I think there is a minor impact to performance as a result as when the iframe swaps you can sometimes still see the astro components load in

Should we open a follow-up to try and make the 'iframe swap' wait for the `astro:hydrate' event - alternatively we can wait until iframe.contentDocument.querySelectorAll('astro-island[ssr]') has a length of zero as that attribute is removed after hydration