Skip to content

slow file save and code action when using the language server #299

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
LukeMauldin opened this issue Jul 7, 2020 · 18 comments
Closed

slow file save and code action when using the language server #299

LukeMauldin opened this issue Jul 7, 2020 · 18 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. upstream-tools Issues that are caused by problems in the tools that the extension depends on.

Comments

@LukeMauldin
Copy link

LukeMauldin commented Jul 7, 2020

What version of Go, VS Code & VS Code Go extension are you using?

  • Run go version to get version of Go
    o version go1.14.2 linux/amd64
  • Run code -v or code-insiders -v to get version of VS Code or VS Code Insiders
 Version: 1.46.1
Commit: cd9ea6488829f560dc949a8b2fb789f3cdc05f5d
Date: 2020-06-17T21:13:08.304Z
Electron: 7.3.1
Chrome: 78.0.3904.130
Node.js: 12.8.1
V8: 7.8.279.23-electron.0
OS: Linux x64 3.10.0-1127.8.2.el7.x86_64
  • Check your installed extensions to get the version of the VS Code Go extension
    • 0.15.0
  • Run go env to get the go development environment details
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/XXX/.cache/go-build"
GOENV="/home/XXX/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GONOPROXY="XXXX"
GONOSUMDB="XXXX"
GOOS="linux"
GOPATH="/home/XXX/go"
GOPRIVATE="XXXX"
GOPROXY="https://XXXXXX"
GOROOT="/apps/go"
GOSUMDB="off"
GOTMPDIR=""
GOTOOLDIR="/apps/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build665326913=/tmp/go-build -gno-record-gcc-switches"

Share the Go related settings you have added/edited

{
    "go.toolsGopath": "/apps/gotools",
    "go.inferGopath": false,
    "go.useLanguageServer": true,
    "go.testFlags": [
        "-count=1",
        "-v"
    ],
    "go.formatTool": "gofmt",
    "go.lintOnSave": "off",
    "go.lintTool": "revive",
    "go.trace.server": "verbose"
}

Describe the bug

I am experiencing extreme slowness and high CPU usage when saving a .go file after modification. I am experiencing it primarily in one project. The project itself is about 10K lines of Go code. It has a relatively small number of dependencies that total about 20K lines of Go code, including some CGO code. During the time that VSCode is waiting, top says that gopls is using between 600%-800% of CPU. No other tasks are taking much time.
Actions such as auto-complete and Go to Definition are fast (complete in around 1 second or less). However, when I save a file, I get a notification from VSCode that it is "Saving the file: Getting code actions from Go". I have turned on gopls tracing and I see messages like the following:

[Trace - 11:29:34 AM] Received response 'textDocument/codeAction - (847)' in 61119ms.
Result: [
    {
        "title": "Fill XXXX with default values",
        "kind": "refactor.rewrite",
        "edit": {
            "documentChanges": [
                {
                    "textDocument": {
                        "version": 379,
                        "uri": "XXXXX"
                    },
                    "edits": [
                        {
                            "range": {
                                "start": {
                                    "line": 202,
                                    "character": 8
                                },
                                "end": {
                                    "line": 202,
                                    "character": 22
                                }
                            },
                            "newText": "XXXX"
                        }
                    ]
                }
            ]
        }
    }
]

[Trace - 11:29:34 AM] Received response 'textDocument/documentLink - (849)' in 60893ms.
Result: [
    {
        "range": {
            "start": {
                "line": 3,
                "character": 2
            },
            "end": {
                "line": 3,
                "character": 5
            }
        },
        "target": "https://pkg.go.dev/fmt"
    },
    {
        "range": {
            "start": {
                "line": 7,
                "character": 2
            },
            "end": {
                "line": 7,
                "character": 23
            }
        },
        "target": "https://pkg.go.dev/github.com/pkg/[email protected]"
    }
]


[Trace - 11:29:34 AM] Received response 'textDocument/documentSymbol - (850)' in 58702ms.

I cannot share the full gopls log because it contains company sensitive symbols. The best I can tell, the bug is related to VSCode asking gopls for an updated list of symbols. I have tried to reproduce the error in Vim with gopls + vim-go and I cannot reproduce the error in the environment. To me, that tells me the error is related to the VSCode Go plugin + gopls and not strictly a gopls bug.
I have been able to duplicate it on multiple machines and my primarily development machine is relatively fast. CPU: Intel(R) Xeon(R) E-2186M and RAM: 32GB

@hyangah
Copy link
Contributor

hyangah commented Jul 7, 2020

@LukeMauldin Thanks for the detailed bug report and the trace. Interesting that you couldn't reproduce it with vim-go.

What were the previous messages before the message 847 was sent? Does the trace (sequence/ordering of messages) look different when using vim-go?

[Trace - 11:29:34 AM] Received response 'textDocument/codeAction - (847)' in 61119ms.

I wonder whether the textDocument/codeAction -(847) was indeed slow and really needed 61sec to complete,
or it was waiting in the queue in gopls blocked by previous potentially expensive requests.

@hyangah hyangah added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. labels Jul 7, 2020
@LukeMauldin
Copy link
Author

Here is a list of the trace statements from VSCode:

[Trace - 11:28:33 AM] Sending request 'textDocument/completion - (843)'.
[Trace - 11:28:33 AM] Sending request 'textDocument/documentHighlight - (844)'.
[Trace - 11:28:33 AM] Received response 'textDocument/completion - (843)' in 54ms. Request failed: JSON RPC cancelled (-32800).
[Trace - 11:28:33 AM] Received response 'textDocument/documentHighlight - (844)' in 53ms. Request failed: JSON RPC cancelled (-32800).
[Trace - 11:28:33 AM] Sending request 'textDocument/documentHighlight - (845)'.
[Trace - 11:28:33 AM] Received response 'textDocument/documentHighlight - (845)' in 29ms.
[Trace - 11:28:33 AM] Sending request 'textDocument/codeLens - (846)'.
[Trace - 11:28:33 AM] Received response 'textDocument/codeLens - (846)' in 2ms.
[Trace - 11:28:33 AM] Sending request 'textDocument/codeAction - (847)'.
[Trace - 11:28:34 AM] Sending request 'textDocument/codeAction - (848)'.
[Trace - 11:28:34 AM] Sending request 'textDocument/documentLink - (849)'.
[Trace - 11:28:36 AM] Sending request 'textDocument/documentSymbol - (850)'.
[Trace - 11:29:34 AM] Received response 'textDocument/codeAction - (847)' in 61119ms.
[Trace - 11:29:34 AM] Received response 'textDocument/codeAction - (848)' in 60910ms.
[Trace - 11:29:34 AM] Received response 'textDocument/documentLink - (849)' in 60893ms.
[Trace - 11:29:34 AM] Received response 'textDocument/documentSymbol - (850)' in 58702ms.

For vim-go, I set let g:go_diagnostics_enabled = 0 but I don't know where to see the trace logs? I looked in /tmp and I see a file named /tmp/gopls-30004.log that seems to have the correct timestamp but it is empty.

@hyangah
Copy link
Contributor

hyangah commented Jul 7, 2020

Thanks @LukeMauldin !

It looks like this is the client-side logging enabled with ("go.trace.server"). To understand where this codeAction (847) is spending, can you please retry by enabling the server-side logging as well ("go.languageServerFlags": [ "serve", "-rpc.trace", "--debug=localhost:6060" ]) that will print out the server-side trace in the gopls (server) output channel. We can check the timing between two traces to see if the request was sitting in the client side or the server is indeed taking 60sec.

Also, with "--debug=localhost:6060" arg, the gopls will bring up a web server for debugging. You can check Trace tab to inspect what the codeAction request is doing, and take the cpu profile. (go tool pprof http://localhost:6060/debug/pprof/profile)

I don't know how to do it in vim-go. (still looking...)

@findleyr
Copy link
Member

findleyr commented Jul 7, 2020

Hi @LukeMauldin, it looks like vim-go has enabled daemon mode for gopls (a feature that I added), and I suspect the logs you're looking at are the daemon logs, which don't contain logs of your individual session and so are mostly (or entirely) empty most of the time. I hadn't really stopped to consider how confusing that could be... filed https://golang.org/issue/40105 to improve this behavior.

All this to say, I don't think g:go_diagnostics_enabled does what you want. From the vim-go help, it looks like that pertains to the display of diagnostics on the current code. Looking at the documentation, I believe you want let g:go_gopls_options = ['-logfile=auto']. That will enable RPC logging to /tmp/gopls-<pid>.log and put your vim-go gopls instance in standalone (not daemon) mode, to make debugging this issue easier.

@LukeMauldin
Copy link
Author

client trace:

[Trace - 2:07:18 PM] Sending request 'textDocument/codeLens - (159)'.
[Trace - 2:07:18 PM] Sending request 'textDocument/codeAction - (160)'.
[Trace - 2:07:18 PM] Received response 'textDocument/codeLens - (159)' in 3ms.
[Trace - 2:07:18 PM] Sending request 'textDocument/documentSymbol - (161)'.
[Trace - 2:07:18 PM] Sending request 'textDocument/codeAction - (162)'.
[Trace - 2:07:46 PM] Received response 'textDocument/codeAction - (160)' in 28132ms.
[Trace - 2:07:46 PM] Received response 'textDocument/documentSymbol - (161)' in 28035ms.
[Trace - 2:07:46 PM] Received response 'textDocument/codeAction - (162)' in 28011ms.

server trace:

[Trace - 14:07:18.860 PM] Sending request 'textDocument/codeLens - (159)'.
[Trace - 14:07:18.862 PM] Received response 'textDocument/codeLens - (159)' in 2ms.
[Trace - 14:07:18.862 PM] Sending request 'textDocument/codeAction - (160)'.
[Trace - 14:07:18.960 PM] Sending request 'textDocument/documentSymbol - (161)'.
[Trace - 14:07:18.985 PM] Sending request 'textDocument/codeAction - (162)'.
[Trace - 14:07:19.556 PM] Sending request 'textDocument/documentLink - (163)'.
[Trace - 14:07:32.265 PM] Received notification 'window/logMessage'.
[Info  - 2:07:32 PM] 2020/07/07 14:07:32 background imports cache refresh starting
[Trace - 14:07:32.305 PM] Received notification 'window/logMessage'.
[Info  - 2:07:32 PM] 2020/07/07 14:07:32 background refresh finished after 40.956003ms
[Trace - 14:07:46.993 PM] Received response 'textDocument/codeAction - (160)' in 28130ms.
[Trace - 14:07:46.993 PM] Received response 'textDocument/documentSymbol - (161)' in 28033ms.
[Trace - 14:07:46.994 PM] Received response 'textDocument/codeAction - (162)' in 28009ms.
[Trace - 14:07:46.999 PM] Sending request 'textDocument/formatting - (164)'.
[Trace - 14:07:47.006 PM] Received notification 'textDocument/publishDiagnostics'.
[Trace - 14:07:47.007 PM] Received notification 'textDocument/publishDiagnostics'.
[Trace - 14:07:47.008 PM] Received response 'textDocument/documentLink - (163)' in 27451ms.

@LukeMauldin
Copy link
Author

I made the changes you requested to my ~/.vimrc file and restarted. I do get the log file in /tmp but it is empty.

.vimrc:

" Golang
" ------
autocmd Filetype go setlocal tabstop=4 shiftwidth=4 softtabstop=4
let g:go_fmt_command = "goimports"
let g:go_fmt_fail_silently = 1
let g:go_highlight_types = 1
let g:go_auto_type_info = 1
let g:go_def_mode='gopls'
let g:go_info_mode='gopls'
"au filetype go inoremap <buffer> . .<C-x><C-o>
let g:go_fmt_autosave = 1
let g:go_auto_type_info = 1
let g:go_gopls_options = ['-logfile=auto']
❰mauldinl❙/tmp❱✔≻ ps -ef | grep gopls
mauldinl  7096  6792 11 14:25 ?        00:00:11 /home/[email protected]/go/bin/gopls -logfile=auto

@findleyr
Copy link
Member

findleyr commented Jul 7, 2020

Ah, sorry, you also need -rpc.trace.

So

let g:go_gopls_options = ['-logfile=auto', '-rpc.trace']

I'm not currently using vim-go, but I'm confirming this now...

@LukeMauldin
Copy link
Author

Below the a similar edit in vim-go. Notice there are no symbol messages to gopls

[Trace - 14:40:03.212 PM] Sending request 'initialize - (1)'.
[Trace - 14:40:03.215 PM] Received response 'initialize - (1)' in 3ms.
[Trace - 14:40:03.267 PM] Sending notification 'initialized'.
[Trace - 14:40:03.268 PM] Received request 'client/registerCapability - (1)'.
[Trace - 14:40:03.268 PM] Sending notification 'textDocument/didOpen'.
[Trace - 14:40:03.292 PM] Sending response 'client/registerCapability - (1)' in 23ms.
[Trace - 14:40:03.295 PM] Received request 'workspace/configuration - (2)'.
[Trace - 14:40:03.295 PM] Received notification 'window/logMessage'.
[Trace - 14:40:03.296 PM] Sending response 'workspace/configuration - (2)' in 0ms.
[Trace - 14:40:03.367 PM] Received notification 'window/logMessage'.
[Trace - 14:40:03.472 PM] Received notification 'window/logMessage'.
[Trace - 14:40:04.023 PM] Sending notification 'textDocument/didChange'.
[Trace - 14:40:04.023 PM] Sending request 'textDocument/definition - (2)'.
[Trace - 14:40:04.026 PM] Received response 'textDocument/definition - (2)' in 2ms.
[Trace - 14:40:04.026 PM] Sending request 'textDocument/hover - (3)'.
[Trace - 14:40:04.027 PM] Received response 'textDocument/hover - (3)' in 0ms.
[Trace - 14:40:05.179 PM] Sending request 'textDocument/definition - (4)'.
[Error - Received] 14:40:05.179 PM #4 no identifier found
[Trace - 14:40:05.234 PM] Received notification 'textDocument/publishDiagnostics'.
[Trace - 14:40:14.693 PM] Sending notification 'textDocument/didChange'.
[Trace - 14:40:14.693 PM] Sending request 'textDocument/definition - (5)'.
[Trace - 14:40:14.711 PM] Received response 'textDocument/definition - (5)' in 18ms.
[Trace - 14:40:14.711 PM] Sending request 'textDocument/hover - (6)'.
[Trace - 14:40:14.712 PM] Received response 'textDocument/hover - (6)' in 0ms.
[Trace - 14:40:15.396 PM] Received notification 'textDocument/publishDiagnostics'.
[Trace - 14:40:15.396 PM] Received notification 'textDocument/publishDiagnostics'.
[Trace - 14:40:15.831 PM] Sending notification 'textDocument/didChange'.
[Trace - 14:40:15.832 PM] Sending request 'textDocument/definition - (7)'.
[Trace - 14:40:15.858 PM] Received response 'textDocument/definition - (7)' in 25ms.
[Trace - 14:40:15.859 PM] Sending request 'textDocument/hover - (8)'.
[Trace - 14:40:15.859 PM] Received response 'textDocument/hover - (8)' in 0ms.
[Trace - 14:40:16.483 PM] Received notification 'textDocument/publishDiagnostics'.
[Trace - 14:40:16.483 PM] Received notification 'textDocument/publishDiagnostics'.
[Trace - 14:40:16.709 PM] Sending notification 'textDocument/didChange'.
[Trace - 14:40:16.710 PM] Sending request 'textDocument/definition - (9)'.
[Error - Received] 14:40:16.741 PM #9 no identifier found
[Trace - 14:40:21.262 PM] Sending notification 'textDocument/didChange'.
[Trace - 14:40:21.262 PM] Sending request 'textDocument/definition - (10)'.
[Error - Received] 14:40:21.292 PM #10 no identifier found
[Trace - 14:40:22.818 PM] Sending notification 'textDocument/didChange'.

@hyangah
Copy link
Contributor

hyangah commented Jul 7, 2020

@LukeMauldin Thank you so much for being patient and providing the trace.
@findleyr Thank you for helping with vim-go configuration.

From vim-go trace, I don't see textDocument/codeAction, which is the head-of-line blocking request in the vscode-go trace.

Let's investigate why textDocument/codeAction takes so long. @LukeMauldin Did you have a chance to 1) get the cpu profile, and 2) visit the debug http server and see Trace -> 'textDocument/codeAction'?

@LukeMauldin
Copy link
Author

I am attaching a cpu profile web trace. And below is the Trace for code/Action

pprof001

 Main Info Memory Metrics RPC Trace
Trace Information
$/cancelRequest last: 35.846µs, longest: 150.55µs
cache.ModTidyHandle last: 46.398127ms, longest: 46.398127ms
cache.ParseModHandle last: 81.065µs, longest: 81.065µs
cache.getFile last: 98.303µs, longest: 1.25994ms
cache.importer.typeCheck last: 26.808254ms, longest: 118.942827ms
cache.parseGo last: 70.952µs, longest: 65.917989ms
cache.view.load last: 210.966319ms, longest: 210.966319ms
client/registerCapability last: 5.02457ms, longest: 5.02457ms
initialize last: 3.995124ms, longest: 3.995124ms
initialized last: 80.672896ms, longest: 80.672896ms
lsp.Server.documentSymbol last: 520.203µs, longest: 121.56281ms
lsp:background-worker last: 3.739901ms, longest: 22.465955274s
mod.Diagnostics last: 1.115198ms, longest: 554.534288ms
queued last: 81.328µs, longest: 22.109508992s
source.AllImportsFixes last: 2.457145ms, longest: 118.157245ms
source.Completion last: 2.176339ms, longest: 189.743117ms
source.DocumentSymbols last: 452.381µs, longest: 121.239317ms
source.Format last: 2.198749ms, longest: 2.198749ms
source.Highlight last: 26.377462ms, longest: 59.413983ms
source.Hover last: 30.518µs, longest: 4.057692ms
source.SignatureHelp last: 1.278129ms, longest: 2.198357ms
source.computeTextEdits last: 163.201µs, longest: 163.201µs
source.diagnostics last: 264.202µs, longest: 3.917253ms
source.hover last: 4.725µs, longest: 25.192µs
textDocument/codeAction last: 3.020183ms, longest: 22.208119687s
textDocument/codeLens last: 869.789µs, longest: 936.077748ms
textDocument/completion last: 27.046284ms, longest: 216.998249ms
textDocument/didChange last: 1.183725ms, longest: 180.405862ms
textDocument/didOpen last: 262.039905ms, longest: 262.039905ms
textDocument/didSave last: 1.054443ms, longest: 1.054443ms
textDocument/documentHighlight last: 26.588532ms, longest: 178.788171ms
textDocument/documentLink last: 21.484518691s, longest: 21.484518691s
textDocument/documentSymbol last: 22.110754297s, longest: 22.110754297s
textDocument/formatting last: 18.939152ms, longest: 18.939152ms
textDocument/publishDiagnostics last: 1.478149ms, longest: 1.478149ms
textDocument/signatureHelp last: 1.479025ms, longest: 2.386738ms
window/logMessage last: 88.312µs, longest: 181.43µs
workspace/configuration last: 1.061485ms, longest: 1.061485ms
workspace/didChangeWatchedFiles last: 660.657µs, longest: 660.657µs
textDocument/codeAction
Last

    0s textDocument/codeAction 3.020183ms start="textDocument/codeAction" method="textDocument/codeAction" direction="in" id="#133"
        2.812976ms label= URI=XXXX
        3.0144ms label= status.code="OK" 
        123.435µs queued 84.956µs start="queued"
        341.171µs source.AllImportsFixes 2.457145ms start="source.AllImportsFixes"

Longest

    0s textDocument/codeAction 22.208119687s start="textDocument/codeAction" method="textDocument/codeAction" direction="in" id="#128"
        915.492µs label= URI=XXXX
        22.208116484s label= status.code="OK" 
        61.014µs queued 12.076µs start="queued"
        133.255µs cache.parseGo 43.705µs start="cache.parseGo" file="XXXX"
        183.159µs source.AllImportsFixes 728.229µs start="source.AllImportsFixes"

@hyangah
Copy link
Contributor

hyangah commented Jul 7, 2020

@LukeMauldin Thank you so much again.
From the profile, we think some of the analyses are expensive. Can you try disabling fillstruct analysis and see if it helps?

    "gopls": {
        "analyses": {
            "fillstruct":false,
        }
    },

@LukeMauldin
Copy link
Author

Where do I put that configuration information? I tried putting it in my VSCode settings JSON file and it is grayed out, like it isn't supported?

@stamblerre
Copy link
Contributor

Yep - that's actually fine - it will still work.

@hyangah hyangah changed the title Plugin extreme slowness slow file save and code action when using the language server Jul 7, 2020
@hyangah hyangah added upstream-tools Issues that are caused by problems in the tools that the extension depends on. and removed WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. labels Jul 7, 2020
@gopherbot
Copy link
Collaborator

Change https://golang.org/cl/241321 mentions this issue: internal/lsp/source: disable fillstruct by default

gopherbot pushed a commit to golang/tools that referenced this issue Jul 8, 2020
The discussion on golang/vscode-go#299 has uncovered the fact that
go/printer is very expensive, and we're calling it frequently on file
changes. Analyzers whose suggested fixes require the original file
content are generally posing issues; this is being discussed on
golang/go#40110.

Updates golang/vscode-go#299

Change-Id: I5cb370c9cb508203e463e7243fc781e75876fe30
Reviewed-on: https://go-review.googlesource.com/c/tools/+/241321
Run-TryBot: Rebecca Stambler <[email protected]>
TryBot-Result: Gobot Gobot <[email protected]>
Reviewed-by: Heschi Kreinick <[email protected]>
@gopherbot
Copy link
Collaborator

Change https://golang.org/cl/241322 mentions this issue: internal/lsp/source: disable fillstruct by default

gopherbot pushed a commit to golang/tools that referenced this issue Jul 8, 2020
The discussion on golang/vscode-go#299 has uncovered the fact that
go/printer is very expensive, and we're calling it frequently on file
changes. Analyzers whose suggested fixes require the original file
content are generally posing issues; this is being discussed on
golang/go#40110.

Updates golang/vscode-go#299

Change-Id: I5cb370c9cb508203e463e7243fc781e75876fe30
Reviewed-on: https://go-review.googlesource.com/c/tools/+/241321
Run-TryBot: Rebecca Stambler <[email protected]>
TryBot-Result: Gobot Gobot <[email protected]>
Reviewed-by: Heschi Kreinick <[email protected]>
(cherry picked from commit d5a7453)
Reviewed-on: https://go-review.googlesource.com/c/tools/+/241322
@LukeMauldin
Copy link
Author

I made the change and from my initial testing, it appears to be working much better. Thank you for helping me resolve the issue so quickly!
A few questions:

  1. Why did vim-go not see the same behavior?
  2. What is the purpose of the fillstruct analysis?

@stamblerre
Copy link
Contributor

Glad to hear it's working better! I believe that vim-go does not yet support fillstruct, which is why.
The fillstruct analysis is used to suggest filling in default values for empty struct literals in users' code, but it seems like we still need to improve it further before it's on by default. We'll be releasing a new version with the analysis off tomorrow.

@hyangah
Copy link
Contributor

hyangah commented Sep 17, 2020

gopls went through many iterations around the fillstruct support, and now the feature offered by default and is pretty stable. I am closing this issue now.

Thanks for your cooperation @LukeMauldin and gopls devs.

@hyangah hyangah closed this as completed Sep 17, 2020
@golang golang locked and limited conversation to collaborators Sep 17, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. upstream-tools Issues that are caused by problems in the tools that the extension depends on.
Projects
None yet
Development

No branches or pull requests

5 participants