x/pkgsite: fails to update latest to reflect latest version #46985
What is the URL of the page with the issue?
What is your user agent?
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:89.0) Gecko/20100101 Firefox/89.0
What did you do?
Navigate to the linked page.
What did you expect to see?
The LATEST text mark on the latest version.
What did you see instead?
A "GO TO LATEST" link on the latest version pointing to the previous version and the previous version being marked as latest.
The text was updated successfully, but these errors were encountered:
@jamalc how was this fixed? I'm seeing it with https://firstname.lastname@example.org, which still points "latest" to v2.0.0, even though v2.0.1 was out over fifteen minutes ago.
Reopening as, at the very least, this seems like a UI/UX bug to me.
What might be different about my module is that I pushed the newer tag, and instead of waiting for pkgsite to naturally pick it up some time later, I manually navigated to https://email@example.com to force it to see the new tag.
I guess that's not what happens with most newer tag versions for modules. But I also didn't want to wait for 20m for the new version to be picked up :)
When we process a module, we follow these steps:
Normally that is fine: we find out about most modules from the index, so the proxy already knows about the module version by the time we see it.
But with "frontend fetch," where a user requests the module pkg.go.dev, that may not be true: the proxy may not learn about the new version until we ask for the zip in step 2, after we've asked the proxy about the latest version. Hence the odd-looking logs:
We should probably get the zip first, then ask for latest versions, then process it. That will require a bit of refactoring.
Ask the proxy for info on the requested module version before doing anything else, even computing the latest versions. This will make the proxy aware of the version if it isn't already. This prevents the failure mode described in the linked issue: the user does frontend fetch on a new, latest version before the proxy sees it, so the latest-version info doesn't know about it. For golang/go#46985 Change-Id: I681da5404cea2d391836d876ac807b714ce88f90 Reviewed-on: https://go-review.googlesource.com/c/pkgsite/+/340123 Trust: Jonathan Amsterdam <firstname.lastname@example.org> Run-TryBot: Jonathan Amsterdam <email@example.com> Reviewed-by: Jamal Carvalho <firstname.lastname@example.org> Reviewed-by: Julie Qiu <email@example.com> TryBot-Result: kokoro <firstname.lastname@example.org>
When a module is requested for the first time through frontend fetch, the index_timestamp should be null, since the module has never appeared in the index before. Drop the not null constraint on module_version_states.index_timestamp to make this possible. For golang/go#46985 Change-Id: I7f08c35307aec485fb212e490031e809971c9341 Reviewed-on: https://go-review.googlesource.com/c/pkgsite/+/341891 Trust: Julie Qiu <email@example.com> Run-TryBot: Julie Qiu <firstname.lastname@example.org> TryBot-Result: kokoro <email@example.com> Reviewed-by: Jonathan Amsterdam <firstname.lastname@example.org>
If a module is introduced for the first time to pkgsite through frontend fetch, and not the index, it won't have a row in module_version_states. A row is now inserted before the fetch process begins if the proxy's info endpoint tells us that this is a valid module. This fixes a bug in the fetch flow where module_version_states.last_processed_at is not updated in upsertModuleVersionState if a row did not already exist. For golang/go#46985 Change-Id: I2a166228df20b1fb935bbabebb5a651da0e2c1ba Reviewed-on: https://go-review.googlesource.com/c/pkgsite/+/341892 Trust: Julie Qiu <email@example.com> Run-TryBot: Julie Qiu <firstname.lastname@example.org> TryBot-Result: kokoro <email@example.com> Reviewed-by: Jonathan Amsterdam <firstname.lastname@example.org>
UpsertModuleVersionStates is changed to UpdateModuleVersionStates. There should never be a situation where UpsertModuleVersionStates is called and a row does not already exist for that module. If that happens, an error is now returned. For golang/go#46985 Fixes golang/go#39628 Change-Id: I357396cee6eb743513ae249609f76f4cd4c19e9b Reviewed-on: https://go-review.googlesource.com/c/pkgsite/+/341860 Trust: Julie Qiu <email@example.com> Run-TryBot: Julie Qiu <firstname.lastname@example.org> Reviewed-by: Jonathan Amsterdam <email@example.com> TryBot-Result: kokoro <firstname.lastname@example.org>
I've just seen a version of this. I tagged