fix: Resolve conditions variable type error in backup selections

[lgallard]

Summary

• Fix conditions variable type from optional(map(any)) to proper nested object structure
• Update selection_by_conditions example to use conditions instead of selection_tags
• Add comprehensive test case for conditions variable validation
• Resolves issue Backup selection using ListOfTags instead of Conditions #169 where conditions caused "attribute types must all match" error

⚠️ Breaking Changes

Type Definition Changes

This PR updates the type definition for all conditions variables from map(any) to a structured object type for better type safety and AWS API compliance.

Variables affected:

• plans.selections.conditions
• selection_conditions
• backup_selections.conditions

Before:

conditions = optional(map(any))

After:

conditions = optional(object({
  string_equals     = optional(map(string))
  string_not_equals = optional(map(string))
  string_like       = optional(map(string))
  string_not_like   = optional(map(string))
}))

Migration Impact

✅ Most users need no changes - If you were using conditions successfully, your code should continue working unchanged.

✅ Fixes broken use cases - Users experiencing "attribute types must all match" errors will now have working code.

⚠️ Potential impact - If you were using conditions in non-standard ways, you may need to update to the structured format.

Migration Example

If you have existing conditions code like:

selections = {
  my_selection = {
    conditions = {
      string_equals = {
        "aws:ResourceTag/Environment" = "prod"
        "aws:ResourceTag/Service"     = "web"
      }
    }
  }
}

No changes needed - this will continue to work.

Changes Made

1. Fixed Variable Type Definition (variables.tf)

Updated all conditions variables to use consistent structured object types that match the AWS Backup API specification.

2. Updated Example (examples/selection_by_conditions/main.tf)

Changed from using selection_tags to properly demonstrating conditions:

selections = {
  selection_by_conditions = {
    conditions = {
      string_equals = {
        "aws:ResourceTag/Environment" = "prod"
        "aws:ResourceTag/Service"     = "web"
      }
    }
  }
}

3. Added Comprehensive Tests

• Created /test/fixtures/terraform/conditions/ test fixture
• Added TestConditionsVariableTypes test case
• Validates that the new structure works without type errors

Problem Solved

Before: Users trying to use conditions would get:

Error: attribute types must all match for conversion to map

After: Users can now use the conditions structure as intended:

selections = {
  selection_tests = {
    conditions = {
      string_equals = {
        "aws:ResourceTag/AutomatedAWSBackup" = "true"
      }
    }
  }
}

Benefits

• ✅ Eliminates type errors - Fixes "attribute types must all match" errors
• ✅ Better type safety - Catches invalid configurations at plan time
• ✅ AWS API compliance - Type structure matches AWS Backup API specification
• ✅ Consistent interface - All conditions variables use the same type definition
• ✅ Better documentation - Clear specification of supported condition types

Test Plan

• Terraform validate passes on all changes
• Example updated to demonstrate proper conditions usage
• New test case validates conditions structure works
• User's exact example from issue Backup selection using ListOfTags instead of Conditions #169 now works
• All existing examples continue to validate successfully

Closes

Closes #169

[lgallard]

bugbot run

[lgallard]

Thanks for the great feedback! 🎯

I've addressed the type inconsistency by updating all conditions variables to use the same structured object type:

Changes Made

1. ✅ Fixed variable

• Before:
• After: Structured object with , , ,

2. ✅ Fixed variable

• Before:
• After: Same structured object type

3. ✅ Already fixed

• Before:
• After: Same structured object type

Result

Now all three conditions variables use the exact same type definition, providing:

• ✅ Consistent interface across the entire module
• ✅ Better type safety and validation
• ✅ No more "attribute types must all match" errors
• ✅ Clearer documentation of what conditions are supported

The changes maintain backward compatibility while providing much better user experience and type safety.

[lgallard]

bugbot run

[lgallard]

📝 Breaking Change Documentation Added

I've updated the PR description to properly document this as a breaking change with:

🔍 What's documented:

• ⚠️ Clear "Breaking Changes" section
• 📋 All affected variables listed
• 🔄 Before/after type definitions
• 📖 Migration guidance for users
• ✅ Examples showing what needs to change (spoiler: most users need no changes)

🎯 Key points for users:

• Most users: No migration needed - existing code continues to work
• Affected users: Those experiencing the original "attribute types must all match" error now have working code
• Rare edge cases: Users who somehow used conditions in non-standard ways may need to update

📚 Documentation follows project patterns:

• Matches format used in existing CHANGELOG.md and MIGRATION.md
• Clear migration examples
• Emphasizes that this "fixes more than it breaks"

This ensures users understand the change and can migrate smoothly if needed!

[lgallard]

bugbot run

[cursor]

✅ BugBot reviewed your changes and found no bugs!

---

Was this report helpful? Give feedback by reacting with 👍 or 👎