Skip to content

fix: populate type from API during resource import#18

Merged
levivannoort merged 8 commits into
mainfrom
prevent-bug-around-resource-import
May 8, 2026
Merged

fix: populate type from API during resource import#18
levivannoort merged 8 commits into
mainfrom
prevent-bug-around-resource-import

Conversation

@levivannoort
Copy link
Copy Markdown
Member

@levivannoort levivannoort commented May 8, 2026

Description

During resource import, the type field was not populated from the API response, leaving it empty in Terraform state. Since type has a RequiresReplace plan modifier, Terraform detected a diff and planned a destroy/recreate — even though the resource already existed with the correct type.

We intentionally skip overwriting type during normal reads to preserve the user's value. During import however, type hasn't been set yet, so we now conditionally populate it from the API when it is null or unknown.

Column resource

Because the Appwrite API returns internal type names that differ from the schema in some cases, a normalizeAPIColumnType function maps them back to user-facing names:

  • "double""float"
  • "linestring""line"
  • "string" + format:"email""email"
  • "string" + format:"enum""enum"
  • "string" + format:"url""url"
  • "string" + format:"ip""ip"
  • All other types are returned as-is by the API.

Additionally:

  • The encrypt field now defaults to false when the API doesn't return it (non-string types), preventing null/unknown state mismatches during import.
  • The default value handling no longer gates on DefaultStr being non-null, so default values are correctly populated during import for bool and numeric columns.

Provider resource

Provider types (sendgrid, smtp, twilio, etc.) match between API and schema, so no normalization is needed — the API value is used directly when type is null/unknown.

Affected resources

  • appwrite_tablesdb_column
  • appwrite_messaging_provider

Type of Change

  • Bug fix
  • New resource or data source
  • Enhancement to existing resource
  • Documentation
  • Other

Checklist

  • make lint passes
  • make test passes
  • make docs has been run and changes committed
  • Acceptance tests added/updated (for resource changes)
  • Examples added/updated (for new resources/data sources)

@greptile-apps
Copy link
Copy Markdown

greptile-apps Bot commented May 8, 2026

Greptile Summary

This PR fixes the type field not being populated during terraform import for appwrite_tablesdb_column and appwrite_messaging_provider resources. Without this fix, type's RequiresReplace plan modifier caused a spurious destroy/recreate on every post-import plan.

  • Column resource: A new normalizeAPIColumnType function maps Appwrite internal API type names ("double""float", "linestring""line", "string" + format → "email"/"enum"/"url"/"ip") back to user-facing schema names during import. The encrypt field now defaults to false for non-string types (matching the schema's Default: false) and the IsUnknown guard is extended to the bool/float64 default branches. UseStateForUnknown plan modifiers are added to created_at and updated_at to suppress spurious diffs on those computed timestamps.
  • Provider resource: Provider type names already match between API and schema, so a simple null/unknown guard populates type directly from prov.Type during import.

Confidence Score: 5/5

The import fix is correctly scoped: both the null/unknown guard and the normalizeAPIColumnType function are only active when type has not been set, so normal read/plan/apply cycles are unaffected.

The core logic correctly addresses the described problem without touching the read path for already-managed resources. The encrypt default is safe because the schema already declares Computed: true, Default: false. Only a minor style inconsistency was found in the new code.

No files require special attention.

Important Files Changed

Filename Overview
internal/services/column/resource.go Adds type normalization during import via normalizeAPIColumnType, correct encrypt defaulting for non-string types, UseStateForUnknown for timestamps, and extends the bool/float64 default write guard to include the IsUnknown case. One minor style nit: "ip" is a raw literal while neighbouring format values use constants.
internal/services/provider/resource.go Straightforward one-block addition: populate type from the API (prov.Type) when the model type is null/unknown during import. Provider type names match between API and schema, so no normalization is needed.

Reviews (7): Last reviewed commit: "fix: add plan modifiers to ensure state ..." | Re-trigger Greptile

Comment thread internal/services/column/resource.go
@levivannoort levivannoort changed the title fix: prevent type overwriting during resource import fix: populate type from API during resource import May 8, 2026
Comment thread internal/common/helpers.go Outdated
Comment thread internal/services/column/resource.go
@levivannoort levivannoort merged commit d79b3d5 into main May 8, 2026
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant