x/tools/gopls: reload metadata on the most durable awaiting context #43652
We try to avoid cloning a snapshot when the previous snapshot has not initialized, by awaiting on a detached context:
However, we also guard initialization with a sync.Once. As has been observed in #43554, it's possible to lose this race to awaitInitialized, such that we run initialization on the snapshot background context, which can be canceled.
As a result, we can clone a snapshot with incomplete metadata. This causes problems for any invalidation logic trying to preserve metadata, such as only invalidating metadata on go.mod saves. Additionally, this was difficult to debug: it would be nice to have a guarantee that we have a linear history of metadata in our snapshots.
After discussing, we think this is a relatively low priority since the current logic should only result in rare and transient breakages.
CC @stamblerre @heschik
The text was updated successfully, but these errors were encountered:
Jumping to definition in a regtest can indirectly lead to a didOpen call, so the awaits added to TestUseGoplsMod to synchronize metadata were ineffectual. On Android, this can lead to the race described in golang/go#43652. But in any case, all this bookkeeping of notifications is fragile. Avoid it entirely by having the fake editor keep track of notification statistics. In the future, we should use this to clean up many existing regtests. For golang/go#43554 For golang/go#39384 Change-Id: Icd1619bd5cdd2f646d1a0050f5beaf2ab1c27f37 Reviewed-on: https://go-review.googlesource.com/c/tools/+/283512 Run-TryBot: Robert Findley <firstname.lastname@example.org> gopls-CI: kokoro <email@example.com> Trust: Robert Findley <firstname.lastname@example.org> TryBot-Result: Go Bot <email@example.com> Reviewed-by: Rebecca Stambler <firstname.lastname@example.org>