Always use /setup-tests endpoint for plan-only attributes

[fivetran-jovanmanojlovic]

Why Terraform Provider Didn't Call the Setup Tests Endpoint

The Terraform provider has two different paths for updating connectors:

Path 1 - PATCH endpoint: Used when "real" attributes change (like config, sync_frequency, paused, etc.)
Path 2 - /setup-tests endpoint: Used when ONLY plan-only attributes change (run_setup_tests, trust_certificates, trust_fingerprints)

The provider checks: "Are there any real attribute changes?"

• If YES → Use PATCH endpoint
• If NO → Use /setup-tests endpoint

Customer's scenario:
They changed BOTH:

• Plan-only attributes: run_setup_tests from false to true
• Other attributes: sync_frequency, paused, pause_after_trial

Since there were "other" changes, the provider chose Path 1 (PATCH endpoint). The PATCH endpoint accepts the run_setup_tests parameter but the API ignores it unless there's also a config change.

Why API Doesn't Run Tests on PATCH Without Config Changes

The backend API has intentional logic in the PATCH endpoint:

Step 1: Check if config or auth fields changed
Step 2: If yes → Apply credential changes and run setup tests
Step 3: If no → Skip the entire setup test execution flow

Customer's PATCH request included:

• run_setup_tests: true (the flag was set)
• data_delay_threshold: changed from 0 to 1
• config: empty object
• auth: empty object

The API checked: "Did config or auth change?"

• Answer: NO (both were empty objects)
• Result: The entire setup test execution flow was skipped
• The run_setup_tests flag was simply ignored

This is intentional API design because setup tests are meant to validate configuration. If no configuration changed, the API assumes there's nothing new to test.

The separate /setup-tests endpoint exists for exactly this use case: Running tests without requiring a config change.

The Fix:
The Terraform provider needs to always check if plan-only attributes changed FIRST, and call /setup-tests endpoint when needed, THEN handle any other attribute changes via PATCH. This ensures setup tests run regardless of what other attributes changed in the same update.

1. Check plan-only attributes BEFORE checking other updates
2. Always call /setup-tests when plan-only attributes change (not just when there are no other updates)
3. Removed plan-only attributes from PATCH request (they're handled separately now)
4. Both endpoints can be called in same update if needed

[fivetran-renat-sh]

In a situation when TF Config is having changes in both run_setup_tests and config, currently it seems it will end up in API requests sequence as:

1. POST /connections/{}/test
2. PATCH /connections/{} with { "config": {"password": "new-password"} },

i.e. setup tests are going to be performed on old config.

If this is so, looks like we need to switch the order - first patch connection, then run tests, as:

if hasUpdates {
  ...
  r.GetClient().NewConnectionUpdate()
  ...
}
if planOnlyAttributesChanged {
  ...
  r.GetClient().NewConnectionSetupTests() 
  ...
}

[fivetran-renat-sh]

Seems we need to add trust-certificates and trust-fingerprints flags, like:

Suggested change

	response, err := r.GetClient().NewConnectionSetupTests().ConnectionID(state.Id.ValueString()).DoCustom(ctx)
	response, err := r.GetClient().NewConnectionSetupTests().
	ConnectionID(state.Id.ValueString()).
	TrustCertificates(trustCertificates...).
	TrustFingerprints(trustFingerprints...).
	DoCustom(ctx)

[fivetran-renat-sh]

Looks like we should not call /connection/{}/test if it is set to false in TF Config.

And have condition

• either

	if planOnlyAttributesChanged && runSetupTestsToPreserve {

• or if we're not calling tests in PATCH /connection/{} then probably

	if (planOnlyAttributesChanged || updatePerformed) && runSetupTestsToPreserve {

[fivetran-renat-sh]

Edit - updated condition suggestion