chore: Omit analyticsSpecs without instanceSize in INFINITE PATCH payloads

[lantoli]

Description

When clearing storage_config on an INFINITE cluster, the forced replicationSpecs PATCH included analyticsSpecs with nodeCount=0 but no instanceSize, causing Atlas to return 400 MISSING_ATTRIBUTE. Atlas was returning 500 instead of 400, which made this provider bug look like an Atlas issue until the 500 was fixed.

Root Cause

The issue was in the Terraform provider, not Atlas. The bug only triggers for INFINITE clusters because:

1. Atlas always returns analyticsSpecs in responses (even with nodeCount: 0)
2. When clearing storage_config, shardSizeLimitRemoved returns true, which sets ForceUpdateAttr = ["replicationSpecs"]
3. ForceUpdateAttr forces the entire replicationSpecs tree into the PATCH, including unchanged attributes
4. The plan's analyticsSpecs became {"nodeCount": 0} without instanceSize because:
   • The plan modifier doesn't copy analyticsSpecs from state when nodeCount == 0 (to avoid ANALYTICS_INSTANCE_SIZE_MUST_MATCH errors)
   • CopyUnknowns copies nodeCount from state but keeps instanceSize unknown (because auto-scaling is enabled, which adds instance_size to keepUnknown)
5. Atlas correctly rejected this with 400

CORE clusters don't have this issue because shardSizeLimitRemoved returns false (CORE doesn't have storageConfig), so ForceUpdateAttr is not set and only changed attributes are included in the PATCH.

The Approach: Why ForceUpdateAttr + omitInvalidInfiniteConfig

Why ForceUpdateAttr is needed:

The Atlas API requires the entire replicationSpecs object to be present in the PATCH request to clear shardSizeLimitGB. Without ForceUpdateAttr:

• State: storageConfig is not present (Atlas doesn't return it after clearing)
• Plan: storageConfig is not present (user removed it from config)
• Result: No diff detected → no PATCH sent → limit is not cleared

ForceUpdateAttr forces the entire replicationSpecs into the PATCH, which tells Atlas to clear the field.

Why omitInvalidInfiniteConfig is needed:

When ForceUpdateAttr forces the entire replicationSpecs into the PATCH, it includes ALL fields, not just the ones that changed. This includes analyticsSpecs with nodeCount=0 but no instanceSize, which INFINITE rejects.

omitInvalidInfiniteConfig removes invalid fields from the PATCH payload before sending it to Atlas.

Why this asymmetry exists:

The asymmetry between CORE and INFINITE is inherent to the feature:

• Only INFINITE supports storageConfig (shardSizeLimitGB)
• Only INFINITE needs to clear it
• CORE doesn't have this field, so it doesn't need this logic

This is not a bug - it's a reflection of the different capabilities of CORE and INFINITE clusters.

The Fix

1. Renamed omitEmptyAutoScalingChildren → omitInvalidInfiniteConfig: The function now handles more than just auto-scaling children - it also omits analyticsSpecs without instanceSize that INFINITE rejects. The new name better reflects its purpose.

2. Added analyticsSpecs removal logic: When nodeCount=0 and instanceSize is not set, the function now sets analyticsSpecs = nil to prevent Atlas from rejecting the PATCH.

Future Improvements

A future PR could explore removing ForceUpdateAttr entirely by using a different mechanism to detect the removal (e.g., explicitly marking storageConfig for removal in the plan). However, this requires verification that the Atlas API accepts this approach and is out of scope for this fix.

Link to any related issue(s): CLOUDP-447210

Type of change:

• Bug fix (non-breaking change which fixes an issue). Please, add the "bug" label to the PR.
• New feature (non-breaking change which adds functionality). Please, add the "enhancement" label to the PR. A migration guide must be created or updated if the new feature will go in a major version.
• Breaking change (fix or feature that would cause existing functionality to not work as expected). Please, add the "breaking change" label to the PR. A migration guide must be created or updated.
• This change requires a documentation update
• Documentation fix/enhancement

Required Checklist:

• I have signed the MongoDB CLA
• I have read the contributing guides
• I have checked that this change does not generate any credentials and that they are NOT accidentally logged anywhere.
• I have added tests that prove my fix is effective or that my feature works per HashiCorp requirements
• I have added any necessary documentation (if appropriate)
• I have run make fix and verified my code
• If changes include deprecations or removals I have added appropriate changelog entries.
• If changes include removal or addition of 3rd party GitHub actions, I updated our internal document. Reach out to the APIx Integration slack channel to get access to the internal document.

Further comments