pr-preview links not being properly updated

[equalsJeffH]

back on 18-Jan-2022, I pushed two new commits to w3c/webauthn#1663 (131d68 and e1e6d94).

However, the PR preview links in the PR's original post continue to use the earlier commit (41ffcbf) from 14-Jan-2022, even though it got the new date correct:

<a href="https://pr-preview.s3.amazonaws.com/w3c/webauthn/pull/1663.html" title="Last updated on Jan 18, 2022, 11:00 PM UTC (41ffcbf)">Preview</a> | <a href="https://pr-preview.s3.amazonaws.com/w3c/webauthn/1663/bc87207...41ffcbf.html" title="Last updated on Jan 18, 2022, 11:00 PM UTC (41ffcbf)">Diff</a>

How do we fix this?
( i note that changing the diff link to use the latest commit---i.e., using e1e6d94 instead of 41ffcbf---does not work and returns an "error page" )

Also, I've noticed some other PR-preview weirdness where it may not overwrite a prior pr-preview block (i.e., the comment + the links) in a PR's original post and instead add the new pr-preview block below the old one, so one ends up with a double set of "Preview | Diff" links in the PR's original post. unfortunately I presently do not have an example I can point to for this.

[tobie]

Thanks for reporting this.

This looks like a weird race condition, between API calls maybe?

To fix it right now, you can just edit the content of the issue's body (a couple of line breaks will do the trick), or push a new commit.

The best way to solve this, imho, is to allow triggering a build manually (e.g. by using a keyword in a new comment or clicking on a link).

Most of the infrastructure is already in place to set that up. It just hasn't been a priority for me given I no longer edit specs and calls for financially supporting this infrastructure haven't gotten anywhere.

With regard to your second issue, I can imagine a case when this happens (i.e. the generated comment gets manually modified). If this shows up again, feel free to open a separate issue about it.

[equalsJeffH]

Thanks for your prompt response @tobie !

To fix it write now, you can just editing the content of the issue's body

ok, thx, I edited w3c/webauthn#1663 (comment) and indeed the pr-preview bot then edited it (according to github).

Perhaps there is some sort of race condition because even though there was an indication that the original post (w3c/webauthn#1663 (comment)) had been "edited by pr-preview (bot)", I opened the "edit" view on it, and the actual diff link had not (yet) been updated to the latest commit (is was still using the earlier commit (41ffcbf)), even though the pop-up view of pr-preview's edit did show it as having properly updated the link to the latest commit (e1e6d94).

Then, after a couple minutes, the pr-preview diff link in the original post was properly updated to the latest commit.

But I wonder why the pr-preview block was not properly updated on 18-Jan-2022, when I pushed those two new commits (131d68 and e1e6d94)?

thanks again!

[tobie]

(Ugh, sorry for the typo fest in my initial reply.)

Perhaps there is some sort of race condition because even though there was an indication that the original post (w3c/webauthn#1663 (comment)) had been "edited by pr-preview (bot)", I opened the "edit" view on it, and the actual diff link had not (yet) been updated to the latest commit (is was still using the earlier commit (41ffcbf)), even though the pop-up view of pr-preview's edit did show it as having properly updated the link to the latest commit (e1e6d94).

Weird things happen, independent of PR Preview, when you try to edit a PR that has been updated in the background, after you loaded the web page.

But I wonder why the pr-preview block was not properly updated on 18-Jan-2022, when I pushed those two new commits (131d68 and e1e6d94)?

Yeah, this makes no sense. The only explanation I can think of for now is an inconsistency between the payload sent to PR Preview when a new commit was pushed and the API responses when the PR was later processed (we don't use the data in the payload to avoid race conditions caused by multiple commits pushed one after the other). Surprising but not entirely impossible.