When provider time out,how to build the releation of tf and client resource

Terraform Providers Plugin Development
1 
For provider plugin development, how to solve the api timeout problem, for example, the creation of resource A is more time-consuming, in the execution of terraform apply command, I wrote a polling method to check the status of resource A in the create method of resource A, when the detection of the resource A is created successfully, the create method of resource A will end normally.

This is a common situation where tf executes apply , and provider execution times out. However, the real resources may be created eventually, but there is no way to subsequently manage the resources that were actually created through tf.

2

I think we solved a similar problem using timeouts.
In model:

Timeouts          timeouts.Value `tfsdk:"timeouts"`

in Schema:

		"timeouts": timeouts.Attributes(ctx, timeouts.Opts{
			Create: true,
		}),

And then (leaving a bit of specific code in)

func (r *ServiceResource) waitForServiceReadiness(ctx context.Context, id string, timeouts timeouts.Value) (*tsClient.Service, error) {
	tflog.Trace(ctx, "ServiceResource.waitForServiceReadiness")

	defaultTimeout := 45 * time.Minute
	timeout, diags := timeouts.Create(ctx, defaultTimeout)

	conf := retry.StateChangeConf{
		Pending:                   []string{"QUEUED", "CONFIGURING", "UNSTABLE"},
		Target:                    []string{"READY"},
		Delay:                     10 * time.Second,
		Timeout:                   timeout,
		PollInterval:              5 * time.Second,
		ContinuousTargetOccurence: 1,
		Refresh: func() (result interface{}, state string, err error) {
			s, err := r.client.GetService(ctx, id)
			if err != nil {
				return nil, "", err
			}
			return s, s.Status, nil
		},
	}
	result, err := conf.WaitForStateContext(ctx)
	if err != nil {
		return nil, err
	}
	return s, nil
}
3

Even if you have an API call timeout before Terraform itself times out, the provider can always return a state value along with the error. That returned state is stored by Terraform, and as long as it contains attributes which can identify the instance, it can be used to later delete or recover it.

If you don’t have enough information to identify the new resource, and the API call failed before supplying you with the necessary data, then that is something lacking in the remote system which Terraform cannot help you recover from.