Nil Pointer Validation Issues

This document consolidates all issues related to nil pointer validation and missing nil checks in the Terraform Provider for Power Platform.

ISSUE 1

API Client: Missing Nil Check for Header Value

File: /workspaces/terraform-provider-power-platform/internal/services/application/api_application.go

Problem: There's no check if operationLocationHeader is empty before usage. If the response header is missing, it could lead to confusing behavior or errors.

Impact: This issue has a medium severity. Skipping this check could lead to downstream HTTP requests with an empty URL or crash from nil/empty string dereferences.

Location: In InstallApplicationInEnvironment after retrieving operationLocationHeader:

Code Issue:

operationLocationHeader := response.GetHeader(constants.HEADER_OPERATION_LOCATION)
tflog.Debug(ctx, "Operation Location Header: "+operationLocationHeader)

_, err = url.Parse(operationLocationHeader)
if err != nil {
    tflog.Error(ctx, "Error parsing location header: "+err.Error())
    return "", err
}

Fix: Add a conditional check for the header before using it:

operationLocationHeader := response.GetHeader(constants.HEADER_OPERATION_LOCATION)
if operationLocationHeader == "" {
    tflog.Error(ctx, "Missing operation location header in response")
    return "", errors.New("missing operation location header in response")
}
tflog.Debug(ctx, "Operation Location Header: "+operationLocationHeader)

_, err = url.Parse(operationLocationHeader)
if err != nil {
    tflog.Error(ctx, "Error parsing location header: "+err.Error())
    return "", err
}

ISSUE 2

Overly Complex and Repetitive Null/Unknown Checks

File: /workspaces/terraform-provider-power-platform/internal/services/environment/models.go

Problem: Throughout the code, there are multiple verbose checks against IsNull() and IsUnknown() to determine if certain values (primarily from the types package) are valid. This leads to repetitive, error-prone code and makes it difficult to determine intent, especially when used in many locations for every optional attribute.

Impact:

• Severity: Low
• Makes the codebase more verbose and harder to maintain.
• May obscure which values are required vs. optional.
• Risk of subtle bugs if a check is missed or made incorrectly.

Location: Widely used pattern such as:

if !environmentSource.EnvironmentGroupId.IsNull() && !environmentSource.EnvironmentGroupId.IsUnknown() {
 environmentDto.Properties.ParentEnvironmentGroup = &ParentEnvironmentGroupDto{Id: environmentSource.EnvironmentGroupId.ValueString()}
}
...
if !environmentSource.AllowBingSearch.IsNull() && !environmentSource.AllowBingSearch.IsUnknown() {
 environmentDto.Properties.BingChatEnabled = environmentSource.AllowBingSearch.ValueBool()
}

Code Issue:

if !value.IsNull() && !value.IsUnknown() {
 // Do something
}

Fix: Refactor into helper functions to abstract the check, increasing readability and maintainability:

func isKnown(value basetypes.Value) bool {
 return !value.IsNull() && !value.IsUnknown()
}

// Usage:
if isKnown(environmentSource.AllowBingSearch) {
 environmentDto.Properties.BingChatEnabled = environmentSource.AllowBingSearch.ValueBool()
}

If such a utility function is already present in a helpers package, use it consistently everywhere.

ISSUE 3

Plan/State Type Safety: Lack of Nil/Zero-Value Handling for Critical Fields

File: /workspaces/terraform-provider-power-platform/internal/services/authorization/resource_user.go

Problem: Fields like plan.EnvironmentId, plan.AadId, and other critical strings are unwrapped with .ValueString() and similar methods without verifying that the plan pointer and these fields are actually non-nil or contain valid data, especially after a failed state extraction or during error or abnormal plan conditions.

Impact: This could lead to runtime panics (nil pointer dereference) or improper resource management if any state/plan is not properly populated or validated, particularly under repeated apply, import, or unusual plan conditions. Severity: High.

Location: For instance, in multiple methods:

hasEnvDataverse, err := r.UserClient.EnvironmentHasDataverse(ctx, plan.EnvironmentId.ValueString())

No prior check that plan (or plan.EnvironmentId) is non-nil or valid. Similar logic applies to state variable as well.

Code Issue:

var plan *UserResourceModel
resp.Diagnostics.Append(req.Plan.Get(ctx, &plan)...)
if resp.Diagnostics.HasError() {
    return
}

// If plan is nil here, this line will panic
hasEnvDataverse, err := r.UserClient.EnvironmentHasDataverse(ctx, plan.EnvironmentId.ValueString())

Fix: Always verify that required state/plan objects are non-nil and contain valid/expected data before dereferencing or calling .ValueString():

var plan *UserResourceModel
resp.Diagnostics.Append(req.Plan.Get(ctx, &plan)...)
if resp.Diagnostics.HasError() || plan == nil || plan.EnvironmentId.IsUnknown() || plan.EnvironmentId.IsNull() {
    // Optionally add a diagnostic here for missing/invalid required field
    return
}

Ensure consistent nil and zero-value checks for all required plan/state fields before dereferencing.

To finish the task you have to

1. Run linter and fix any issues
2. Run UnitTest and fix any of failing ones
3. Generate docs
4. Run Changie

Changie Instructions

Create only one change log entry. Do not run the changie tool multiple times.

changie new --kind <kind_key> --body "<description>" --custom Issue=<issue_number>

Where:

• <kind_key> is one of: breaking, changed, deprecated, removed, fixed, security, documentation
• <description> is a clear explanation of what was fixed/changed search for 'copilot-commit-message-instructions.md' how to write description.
• <issue_number> pick the issue number or PR number