aws-toolkit-vscode: "Scanning CloudFormation templates..." notification never goes away/finishes
Problem
Steps to reproduce the issue
- Install AWS Toolkit
- Open a large workspace with lots of files and folders.
- Observe that on any file open, you see this “Scanning CloudFormation templates…” notification.
- Close the notification.
- Open a new file.
- And the notification re-appears with the same loading bar and never finishes.
Expected behavior
My assumption is that the file scan is just never completing because there are so many files and if so, perhaps you could utilize the user’s search exclude list to ignore irrelevant files.
Or give me an option to fully disable this feature and prevent CFN template discovery / watching.
System details (run the AWS: About Toolkit command)
- OS: Linux x64 5.4.242-162.348.amzn2int.x86_64
- Visual Studio Code version: 1.78.2
- AWS Toolkit version: 1.74.0
About this issue
- Original URL
- State: closed
- Created a year ago
- Reactions: 7
- Comments: 21 (11 by maintainers)
Commits related to this issue
- perf(sam): skip files excluded by user settings Problem: "Scanning CloudFormation templates..." takes a long time on big workspaces, and there is no workaround. #3510 Solution: When scanning for CFN... — committed to aws/aws-toolkit-vscode by justinmk3 10 months ago
- perf(sam): skip files excluded by user settings Problem: "Scanning CloudFormation templates..." takes a long time on big workspaces, and there is no workaround. #3510 Solution: When scanning for CFN... — committed to aws/aws-toolkit-vscode by justinmk3 10 months ago
- perf(sam): skip files excluded by user settings Problem: "Scanning CloudFormation templates..." takes a long time on big workspaces, and there is no workaround. #3510 Solution: When scanning for CFN... — committed to aws/aws-toolkit-vscode by justinmk3 10 months ago
- perf(sam): skip files excluded by user settings Problem: "Scanning CloudFormation templates..." takes a long time on big workspaces, and there is no workaround. #3510 Solution: When scanning for CFN... — committed to aws/aws-toolkit-vscode by justinmk3 10 months ago
- perf(sam): skip files excluded by user settings Problem: "Scanning CloudFormation templates..." takes a long time on big workspaces, and there is no workaround. #3510 Solution: When scanning for CFN... — committed to aws/aws-toolkit-vscode by justinmk3 10 months ago
- perf(startup): avoid templateRegistry in awsFiletypes.ts Problem: The AWS Documents handler (`awsFiletypes.ts`) is triggered frequently. It calls `globals.templateRegistry` which triggers an expensiv... — committed to aws/aws-toolkit-vscode by justinmk3 8 months ago
- perf(startup): avoid templateRegistry in awsFiletypes.ts Problem: The AWS Documents handler (`awsFiletypes.ts`) is triggered frequently. It calls `globals.templateRegistry` which triggers an expensiv... — committed to aws/aws-toolkit-vscode by justinmk3 8 months ago
- perf(startup): avoid templateRegistry in awsFiletypes.ts Problem: The AWS Documents handler (`awsFiletypes.ts`) is triggered frequently. It calls `globals.templateRegistry` which triggers an expensiv... — committed to aws/aws-toolkit-vscode by justinmk3 8 months ago
- perf(startup): avoid templateRegistry in awsFiletypes.ts Problem: The AWS Documents handler (`awsFiletypes.ts`) is triggered frequently. It calls `globals.templateRegistry` which triggers an expensiv... — committed to aws/aws-toolkit-vscode by justinmk3 8 months ago
- perf(startup): avoid templateRegistry in awsFiletypes.ts Problem: The AWS Documents handler (`awsFiletypes.ts`) is triggered frequently. It calls `globals.templateRegistry` which triggers an expensiv... — committed to aws/aws-toolkit-vscode by justinmk3 8 months ago
- perf(startup): avoid templateRegistry in awsFiletypes.ts Problem: The AWS Documents handler (`awsFiletypes.ts`) is triggered frequently. It calls `globals.templateRegistry` which triggers an expensiv... — committed to aws/aws-toolkit-vscode by justinmk3 8 months ago
- perf(startup): avoid templateRegistry in awsFiletypes.ts Problem: The AWS Documents handler (`awsFiletypes.ts`) is triggered frequently. It calls `globals.templateRegistry` which triggers an expensiv... — committed to aws/aws-toolkit-vscode by justinmk3 8 months ago
- perf(startup): avoid templateRegistry in awsFiletypes.ts #3962 Problem: The AWS Documents handler (`awsFiletypes.ts`) is triggered frequently. It calls `globals.templateRegistry` which triggers an ... — committed to aws/aws-toolkit-vscode by justinmk3 8 months ago
- Merge master into feature/codewhisperer/assisted-code-remediation (#3929) * auth: ellipsis + right click options for `Developer Tools` (#3925) This commit allows user to right click to root CW or ... — committed to aws/aws-toolkit-vscode by aws-toolkit-automation 8 months ago
- Merge from public (#1275) * CodeWhisperer: Security Issue Hover Provider (#3884) * add hover provider for security issues * add unit tests * codewhisperer: add markdown content for hover (#3... — committed to aws/aws-toolkit-vscode by ctlai95 8 months ago
- Merge acr into awsq (#1319) * CodeWhisperer: TS, C#, Cloud Formation[JSON & YAML/YML] & Terraform [TF & HCL] language support for Security Scans (#1182) * CW: Add TS language for CG Security scans... — committed to aws/aws-toolkit-vscode by ctlai95 7 months ago
- Merge feature/vector into feature/awsq (#1396) * CodeWhisperer: TS, C#, Cloud Formation[JSON & YAML/YML] & Terraform [TF & HCL] language support for Security Scans (#1182) * CW: Add TS language fo... — committed to aws/aws-toolkit-vscode by leigaol 7 months ago
The correct approach is to allow users who do not have CloudFormations to disable it. Not exclude locations. ZERO scanning.
Not yet, but performance is one of our priorities in the near/medium-term.
Adding a setting to disable this is non-trivial because SAM features depend on it. The work needed to make a “disable” setting work is similar to the work needed for the scan to be “on-demand”.
Meanwhile you can disable this by setting
files.watcherExclude.This is not helpful. The CloudFormation scan hangs vscode at startup. I don’t want the scan at all, but I want search to work for my other extensions and find in files and the global setting disables that.
So, after a few days with the affinity setting enabled, I still notice very big delays in other extensions while the “Scanning CloudFormation templates…” task is running. Is there a way to disable CloudFormation linting altogether? I do not use CloudFormation templates at all and my workspace is very big, which I suspect is the reason why the scanning for templates takes forever to complete.
Unfortunately, disabling via
files.watcherExcludedoes not only affect the AWS Toolkit functionality and is an unacceptable workaround, as we do rely on other functionality using file watchers.I think it would at least be good to add one non-standard-vscode setting to that list, so that one could use that setting to exclude parts of hiw workspace, while not affecting other VSCode functionalities.
I’m not 100% sure what the sequencing is, but I’ve also merged https://github.com/aws/aws-toolkit-vscode/pull/3931 , which was rescanning the workspace multiple times for each runtime we support…I’m not sure if VS Code attempts to run this scanner at the same time as the YAML one (where the message is generated from).
If you want to give this a crack before the next release, you can try the latest prerelease VSIX: https://github.com/aws/aws-toolkit-vscode/releases/tag/prerelease
@justinmk3 Do we have a timeline on when (or if) this setting (to disable scans) be released?
Supporting “exclude patterns” was a low-risk way to ameliorate some (but not all) scenarios. The next step in improving this behavior is to make it “just in time” so that it doesn’t try to scan until SAM features are actually requested.
Implemented in AWS Toolkit 1.86. All directories mentioned by the standard vscode settings
files.exclude,search.exclude, andfiles.watcherExclude, are ignored by the “Scanning CloudFormation templates” feature.That provides a flexible workaround, but the root cause of the performance issue could still be improved, so leaving this issue open.
I’ll enable the setting and give it an in-depth try tomorrow, from a first look it seems that it improves the situation greatly already.