feat: Add AI Model Config resource and data source

[tracisiebel]

Wait!

⚠️ This PR is NOT ready to merge - CI is failing with a validation error that needs to be fixed.

• ❌ No comprehensive tests added for AI Model Config
• ❌ No data source tests
• ❌ Docs not updated (make generate failed locally due to goenv setup)
• ⚠️ CI failing: "the 'id' attribute cannot be marked Required" - needs field rename

Summary

This PR adds support for AI Model Configs in the LaunchDarkly Terraform provider by:

1. Adding launchdarkly_ai_model_config resource and data source
2. Upgrading api-client-go from v17.1.0 to v17.2.0 to access AI Config endpoints
3. Fixing breaking changes from the API client upgrade in unrelated files

Changes

New Resources

• Resource: launchdarkly_ai_model_config - Create and manage AI model configurations
• Data Source: data.launchdarkly_ai_model_config - Read AI model configuration data

Schema Design

All fields are marked ForceNew: true because the API has no PATCH/Update endpoint (only POST, GET, DELETE). Any changes to an AI Model Config will force resource recreation.

Fields:

• project_key (Required, ForceNew)
• key (Required, ForceNew)
• name (Required, ForceNew)
• id (Required, ForceNew) - Model identifier for third-party providers ⚠️ CONFLICTS WITH TERRAFORM RESERVED FIELD
• model_provider (Optional, ForceNew) - Renamed from "provider" to avoid Terraform reserved name
• icon (Optional, ForceNew)
• params (Optional, ForceNew) - TypeMap for model parameters
• custom_params (Optional, ForceNew) - TypeMap for custom parameters
• tags (Optional, ForceNew)
• cost_per_input_token (Optional, ForceNew)
• cost_per_output_token (Optional, ForceNew)
• version (Computed)
• global (Computed)

API Client Upgrade (v17.1.0 → v17.2.0)

The upgrade introduced breaking changes that required fixes:

1. flag.Environments type change: Changed from map[string]ldapi.FeatureFlagConfig to *map[string]ldapi.FeatureFlagConfig

   • Fixed in: feature_flag_environment_helper.go, data_source_launchdarkly_feature_flag_environment_test.go, resource_launchdarkly_feature_flag_environment_test.go
   • Added nil checks and pointer dereferences

2. MetricPost.IsActive removed: Field no longer exists in v17.2.0

   • Fixed in: resource_launchdarkly_metric.go
   • Removed the field from metric creation

3. Unused helper functions: Removed jsonMarshal and jsonEqual from helper.go after switching from JSON strings to TypeMap

Known Issues

⚠️ Critical: CI Validation Error

Error: InternalValidate
resource launchdarkly_ai_model_config: the "id" attribute cannot be marked Required

Root Cause: The id field conflicts with Terraform's reserved id field (used for resource IDs). The schema field needs to be renamed to model_id or similar.

Impact: All acceptance tests fail immediately with this validation error, preventing any tests from running.

Missing Tests

No acceptance tests were added for:

• Resource CRUD operations
• Data source reads
• Import functionality
• Field validation
• ForceNew behavior

Documentation

Documentation was not generated due to local goenv setup issues. The make generate command needs to be run successfully before merge.

Human Review Checklist

Critical Items:

1. ⚠️ Fix the "id" field conflict - Rename to model_id or similar to avoid Terraform reserved name
2. Review field naming choices (model_provider for the LLM provider field)
3. Verify the API client upgrade didn't break anything else (only tested feature flags and metrics)
4. Decide on testing requirements before merge

Schema Review:
5. Confirm all fields should be ForceNew (no Update endpoint exists)
6. Review TypeMap usage for params/customParams vs JSON strings
7. Verify tags field override to add ForceNew is correct

Side Effects:
8. Review feature flag environment test changes (pointer dereference)
9. Review metric resource changes (IsActive removal)
10. Check if any other resources use the v17.2.0 API changes

Testing

Local Testing: Compilation passes with go test ./launchdarkly -c

CI Status: ❌ Failing - validation error prevents all tests from running

Links

• Devin Session: https://app.devin.ai/sessions/e41fa8370ea042beb14d4de2a208f98c
• Requested by: traci@launchdarkly.com (@tracisiebel)

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment and CI monitoring

[sloloris]

do you actually want to force new for resources that change their name? this will trigger a delete and then a recreation of a totally new resource with the same properties

[sloloris]

does the user assign this or does LD? if LD assigns this it should always be computed and the force new is moot

[sloloris]

are these parameters fixed? if so i would recommend trying for an object rather than forcing hte user to pass a json string similar to the API

[sloloris]

ditto - not convinced this should be a string

[sloloris]

ditto force new

[sloloris]

ditto force new

[sloloris]

okay i see devin just thinks everything should force new. i'm assuming this has something to do with the no update thing, but i still think someone should look at this more closely

[devin-ai-integration]

Thank you for the detailed review! I want to address the ForceNew concerns and explain my reasoning.

The Core Issue: No PATCH Endpoint

I've investigated the API client v17.2.0 and the available methods for AI Model Configs are:

• PostModelConfig (create)
• GetModelConfig (read)
• DeleteModelConfig (delete)
• ListModelConfigs (list)

There is no PatchModelConfig method in the API client. Without an update endpoint, I cannot implement Terraform's UpdateContext function. If I remove ForceNew from user-settable fields, Terraform would plan an update but fail at apply time because there's no API to call.

Is there an undocumented or planned update endpoint I should be using instead? If so, I'm happy to implement proper updates and remove ForceNew where appropriate.

Addressing Your Specific Comments:

1. params/customParams as objects: You're absolutely right! The OpenAPI spec shows these as type: "object", not strings. I'll change them to schema.TypeMap to provide a better UX.

2. ID field: According to the OpenAPI spec, id is required in ModelConfigPost, so it's user-provided (not LD-assigned). I'll keep it as Required: true with ForceNew: true.

3. GLOBAL field: You're correct - global is NOT in ModelConfigPost, so it's server-assigned. I'll change it to Computed: true only and remove ForceNew.

4. ForceNew on other fields: Fields like name, provider, icon, costPerInputToken, costPerOutputToken, etc. are all user-provided in ModelConfigPost. Without a PATCH endpoint, these need ForceNew: true to maintain correct Terraform semantics. Otherwise, users would see planned updates that fail at apply time.

My Plan:

• Change params/customParams to TypeMap objects
• Fix GLOBAL to be Computed-only
• Keep ForceNew on user-settable fields (unless you can point me to an update endpoint)
• Add Beta API header if needed

Please let me know if there's an update endpoint I'm missing, or if you'd prefer a different approach!

[sloloris]

is this user-defined or does LD auto-assign the value? if the former it should not be computed

[sloloris]

hi @tracisiebel !

before we approve and release this, could you get someone from your team who is familiar with the resource and the API to review this, especially the schema? i also don't think we have many (if any) other resources that don't allow update / have an associated patch API - i think it is worth having a more deliberate conversation about how we actually expect the provider to behave in this situation.

also, we will want to ensure it is thoroughly tested before we merge.