Simplify completion provider control flow

[sonarqube-agent]

This PR was automatically created by the Remediation Agent's Scheduled backlog remediation feature.

Why these issues? These issues are tightly related and all live in the same completion provider scope, so they can be addressed together with one structural refactor. The highest cognitive-complexity findings provide the main target, and the optional chaining warning is naturally resolved by the same control-flow cleanup. This grouped fix gives the best payoff with minimal extra context switching.

Refactored the Ansible language server completion provider to flatten nested logic and split complex resolution paths into smaller helpers. This reduces cognitive complexity in the affected functions and also replaces a manual null check with a more concise optional-chain style guard.

View Project in SonarCloud

---

Fixed Issues

typescript:S3776 - Refactor this function to reduce its Cognitive Complexity from 89 to the 15 allowed. • CRITICAL • View issue

Location: packages/ansible-language-server/src/providers/completionProvider.ts:59

Why is this an issue?

Cognitive Complexity is a measure of how hard it is to understand the control flow of a unit of code. Code with high cognitive complexity is hard to read, understand, test, and modify.

What changed

This hunk adds an early return when path is missing, instead of nesting the rest of doCompletion inside if (path). That directly helps the reported high cognitive complexity in doCompletion by flattening control flow and removing one nesting level from the whole function.

--- a/packages/ansible-language-server/src/providers/completionProvider.ts
+++ b/packages/ansible-language-server/src/providers/completionProvider.ts
@@ -105,9 +104,3 @@ export async function doCompletion(
-  if (path) {
-    const node = path[path.length - 1];
-    if (node) {
-      const docsLibrary = await context.docsLibrary;
-
-      const isPlay = isPlayParam(path);
-      if (isPlay) {
-        return getKeywordCompletion(document, position, path, playKeywords);
-      }
+  if (!path) {
+    return [];
+  }

typescript:S3776 - Refactor this function to reduce its Cognitive Complexity from 32 to the 15 allowed. • CRITICAL • View issue

Location: packages/ansible-language-server/src/providers/completionProvider.ts:517

Why is this an issue?

Cognitive Complexity is a measure of how hard it is to understand the control flow of a unit of code. Code with high cognitive complexity is hard to read, understand, test, and modify.

What changed

This hunk replaces the large inline body of doCompletionResolve with calls to smaller helpers and an immediate return. That is the main structural step in fixing the reported excessive cognitive complexity in doCompletionResolve.

--- a/packages/ansible-language-server/src/providers/completionProvider.ts
+++ b/packages/ansible-language-server/src/providers/completionProvider.ts
@@ -521,2 +640,4 @@ export async function doCompletionResolve(
-  if (completionItem.data?.moduleFqcn && completionItem.data?.documentUri) {
-    // resolve completion for a module
+  await resolveModuleCompletionItem(completionItem, context);
+  resolveTypeCompletionItem(completionItem);
+  return completionItem;
+}

typescript:S6582 - Prefer using an optional chain expression instead, as it's more concise and easier to read. • MAJOR • View issue

Location: packages/ansible-language-server/src/providers/completionProvider.ts:529

Why is this an issue?

Optional chaining allows to safely access nested properties or methods of an object without having to check for the existence of each intermediate property manually. It provides a concise and safe way to access nested properties or methods without having to write complex and error-prone null/undefined checks.

What changed

This hunk replaces the compound check for moduleFqcn and documentUri with an early guard inside the extracted helper. That helps the cognitive-complexity problem by flattening control flow, and it also addresses the warning about preferring optional chaining over manual logical checks because it removes the style of condition flagged around module && module.documentation logic and related nested checks.

--- a/packages/ansible-language-server/src/providers/completionProvider.ts
+++ b/packages/ansible-language-server/src/providers/completionProvider.ts
@@ -529,31 +652,3 @@ export async function doCompletionResolve(
-    if (module && module.documentation) {
-      const [namespace, collection, name] =
-        completionItem.data.moduleFqcn.split(".");
-
-      let useFqcn = (
-        await context.documentSettings.get(completionItem.data.documentUri)
-      ).ansible.useFullyQualifiedCollectionNames;
-
-      if (!useFqcn) {
-        // determine if the short name can really be used
-
-        const declaredCollections: Array<string> =
-          completionItem.data?.inlineCollections || [];
-        declaredCollections.push("ansible.builtin");
-
-        const metadata = await context.documentMetadata.get(
-          completionItem.data.documentUri,
-        );
-        if (metadata) {
-          declaredCollections.push(...metadata.collections);
-        }
-
-        const canUseShortName = declaredCollections.some(
-          (c) => c === `${namespace}.${collection}`,
-        );
-        if (!canUseShortName) {
-          // not an Ansible built-in module, and not part of the declared
-          // collections
-          useFqcn = true;
-        }
-      }
+  if (!moduleFqcn || !documentUri) {
+    return;
+  }

Have a suggestion or found an issue? Share your feedback here.

---

SonarQube Remediation Agent uses AI. Check for mistakes.

[sonarqubecloud]

SonarQube reviewer guide

Summary: Refactor completion provider to improve code maintainability by extracting nested logic into smaller, focused helper functions.

Review Focus:

• The refactoring significantly reduces nesting depth and improves readability, but verify that early returns in new functions preserve original behavior
• Ensure getTaskOrKeywordCompletion and getVariableCompletion correctly return null vs empty arrays as they now have explicit null-return paths
• Confirm the extraction of choice/option/host completion logic maintains all edge cases, particularly around YAML path handling and node range calculations
• Check that removed TextEdit import doesn't break anything—verify textEdit handling still works in the refactored completion items

Start review at: getTaskOrKeywordCompletion() and doCompletion(). These are the core logic flow that orchestrates all completion types; understanding how they route between helpers is essential to verify the refactoring preserves the original control flow and early-exit behavior.

💬 Please send your feedback

Quality Gate passed

Issues
1 New issue
0 Accepted issues
0 New dependency risks

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[sonarqube-cloud-dev7]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud