textDocument/didChange -- file is not open

[amasover]

Server Version

0.3.2

Terraform Version

0.12.26

Client Version

Emacs with lsp-mode 20200612.455 from Melpa

Terraform Configuration Files

resource "azurerm_container_group" "test" {
  name = "test"
  location = var.location
  resource_group_name = "test"
  ip_address_type = "public"

  os_type = "Linux"
  container {
  0
}
}

Log Output

https://gist.github.com/amasover/f7d8c8e7091b316079853da6bff80907

Expected Behavior

I should be able to continue to edit the Terraform file and see autocomplete information without errors.

Actual Behavior

This error occurred:

2020/06/12 13:37:44 server.go:294: Discarding error from notification to "textDocument/didChange": Old version (626) received, current version is 627. Unable to update file:///home/aaron/code/terraform-modules/atlantis/main.tf. This is likely a bug, please report it.

And then every subsequent autocomplete request to textDocument/didChange resulted in this error (until I restarted the server):

2020/06/12 13:37:49 server.go:294: Discarding error from notification to "textDocument/didChange": file is not open: file:///home/aaron/code/terraform-modules/atlantis/main.tf

Steps to Reproduce

I was able to (unreliably) reproduce this a couple of times with the following steps:

1. Open a Terraform file in Emacs. Use the Azure provider
2. Create a resource azurerm_container_group and start filling it in with required fields
3. Start creating a container block inside that resource and autocomplete it
4. Undo creation of the container block
5. Repeat steps 3-4 several times

However, the above instructions seem unreliable....

I was able to reproduce this by repeating steps 3-4 about five times, and I got the error.

Restarted the language server, repeated steps 3-4 about five times, and got the error again.

Restarted the language server again and tried repeating steps 3-4 about fifty times...didn't see the error.

I apologize as I'm not able to figure out how to reproduce this more reliably.

[radeksimko]

Thank you for the report and all the details @amasover

I originally thought this would be a client-side bug where the client is sending requests in the wrong order (which it IMO shouldn't), but after looking closer at the log it appears that this may in fact be the server processing requests in the wrong order.

The requests are received in the following order: 624, 625, 626, 627 but processed in the following order: 624, 625, 627, 626.

It appears that this is the bug @njuCZ mentioned to me, related to the fact that #120 didn't actually make requests sequential.

[radeksimko]

I have opened upstream issue: creachadair/jrpc2#20

[radeksimko]

The maintainer of the upstream library kindly came up with a patch which I will test myself in coming days.

I also made a snapshot build with jrpc2 pinned to the branch with the patch:

• terraform-ls_v0.5.1-SNAPSHOT-09d8b32_openbsd_amd64.zip
• terraform-ls_v0.5.1-SNAPSHOT-09d8b32_freebsd_arm.zip
• terraform-ls_v0.5.1-SNAPSHOT-09d8b32_openbsd_386.zip
• terraform-ls_v0.5.1-SNAPSHOT-09d8b32_linux_386.zip
• terraform-ls_v0.5.1-SNAPSHOT-09d8b32_windows_386.zip
• terraform-ls_v0.5.1-SNAPSHOT-09d8b32_linux_amd64.zip
• terraform-ls_v0.5.1-SNAPSHOT-09d8b32_freebsd_amd64.zip
• terraform-ls_v0.5.1-SNAPSHOT-09d8b32_solaris_amd64.zip
• terraform-ls_v0.5.1-SNAPSHOT-09d8b32_windows_amd64.zip
• terraform-ls_v0.5.1-SNAPSHOT-09d8b32_freebsd_386.zip
• terraform-ls_v0.5.1-SNAPSHOT-09d8b32_linux_arm.zip
• terraform-ls_v0.5.1-SNAPSHOT-09d8b32_darwin_amd64.zip

terraform-ls_v0.5.1-SNAPSHOT-09d8b32_SHA256SUMS

151c3f5d4230695530afb2ea6085d1b57fc2ce0778bdcfaccccc1b1fb8983ec2  terraform-ls_v0.5.1-SNAPSHOT-09d8b32_openbsd_amd64.zip
180421c5ca8de710ae97d5e25a61c55fa67c327e7ce4296cff9ef369e2e29844  terraform-ls_v0.5.1-SNAPSHOT-09d8b32_freebsd_arm.zip
26280c6e7acd36ea84a8e9291ca10325b82e8a356b81626bdec7eab3dac2c37e  terraform-ls_v0.5.1-SNAPSHOT-09d8b32_openbsd_386.zip
38bffedb2c20fb2244c5747d22e14d0e04bea541c8be33d605f100246a24d896  terraform-ls_v0.5.1-SNAPSHOT-09d8b32_linux_386.zip
574676fcefcb68e507617908f843cb9e355eb9d74dff1761fcb662cc5c44b2e9  terraform-ls_v0.5.1-SNAPSHOT-09d8b32_windows_386.zip
727843d4b05ab88f51357e7380d2fe6cf4b466404f5486b97224828650888884  terraform-ls_v0.5.1-SNAPSHOT-09d8b32_linux_amd64.zip
73fd9de6e514c51a5c2c0dc0964b6c94bce8f1d41232a089b0a433d508a7c905  terraform-ls_v0.5.1-SNAPSHOT-09d8b32_freebsd_amd64.zip
b672c18b6edc4a4cc48903a0238a88b29ff3d48c21babc954bea7d1adf85433e  terraform-ls_v0.5.1-SNAPSHOT-09d8b32_solaris_amd64.zip
e7104083da3680def2f926faef47a27c322c58ccd1f86a8d01e70ade35993073  terraform-ls_v0.5.1-SNAPSHOT-09d8b32_windows_amd64.zip
ea03b0ee08492dff9b6944f72ca6f420d831b7664ed3693c3830dd3ae9c9a3e8  terraform-ls_v0.5.1-SNAPSHOT-09d8b32_freebsd_386.zip
f226484afeb9ead35f8f4d61b1d6ed27f982063debeefa45ca037398bcd4fc84  terraform-ls_v0.5.1-SNAPSHOT-09d8b32_linux_arm.zip
f2f5f96fa88aee7926b5038071889202f59feab9a6d836236c97eeedd82f599b  terraform-ls_v0.5.1-SNAPSHOT-09d8b32_darwin_amd64.zip

@amasover Do you have a spare moment to help verifying that this fixes the problem on your side too using any of the above builds? 🙏

[amasover]

@radeksimko I tested with the snapshot build trying autocomplete a few hundred times in an attempt to reproduce the bug, and got no errors. I guess we can't be completely sure that it's fixed since I was never able to reproduce reliably in the first place. But I think it's likely fixed.

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the context necessary to investigate further.