Module provider 

Typed provider-RPC wrappers (configure / plan / apply) over a dialed channel, speaking magma-cty values. The layer that makes apply real. Typed provider-RPC wrappers — the tfplugin5/6 Provider service over a dialed [Channel], speaking magma_cty values.

This is the layer that lets magma-apply stop being a structural no-op and actually create resources (magma#2). Plugin::dial hands back a gRPC Channel + the negotiated protocol; [ProviderConn] wraps the matching generated client and exposes the four RPCs the apply engine needs:

• [ProviderConn::get_schema] — resource type → implied [CtyType].
• [ProviderConn::configure] — provider credentials / settings.
• [ProviderConn::plan_resource_change] — provider-proposed new state.
• [ProviderConn::apply_resource_change] — create/update/delete; the returned DynamicValue is the resource’s new state.

Both protocols are dispatched. SDKv2 providers (github — galho’s target — aws, …) speak tfplugin5; framework providers speak tfplugin6. ProviderConn::new selects the client from the handshake’s negotiated PluginProtocol. The schema parser is shared (v5 schemas convert to v6 via crate::schema::block5_implied_type); error-severity diagnostics (severity 1 in both protocols) become a typed [ProviderError].

Structs

Diag

PlannedChange

The provider’s full response to PlanResourceChange: the normalized planned state PLUS the attribute paths the provider says force a destroy+create instead of an in-place update (“requires replace”).

ProviderConn

A connected provider — the protocol-matched client over a dialed channel.

ProviderSchema

A provider’s schema reduced to the implied cty types the apply codec needs: the provider-config type + each managed resource’s type.

Enums

ProviderError

Severity

Functions

is_retryable

Is this provider error worth retrying with backoff? True for transient conditions — chiefly provider-side RATE LIMITING (github/cloud secondary rate limits surface as error diagnostics or transport errors) and transient transport faults. The tfplugin Diagnostic carries no status code, so detection is text-pattern matching on the diagnostic + transport strings. Permanent errors (bad config, schema, auth-denied) return false so they fail fast instead of looping.