Fix DestinationConfigResponse struct format.

[georgi0u]

w/r/t DestinationConfigResponse:

IsPrivateKeyEncrypted comes back as a bool, not a string, and thus fails unmarshalling, as written.

See:

json: cannot unmarshal bool into Go struct field DestinationConfigResponse.data.config.is_private_key_encrypted of type string;

We — Runway.com — are depending on the fork this PR is derived from, until this is fixed.

---

I've read your CONTRIBUTING.md and assume one-liners are probably still welcome.

[beevital]

@georgi0u it's better to use DoCustom and ConfigCustom (it's a map) - to avoid any issues with config types.

[georgi0u]

@georgi0u it's better to use DoCustom and ConfigCustom (it's a map) - to avoid any issues with config types.

@beevital —

Can that be true? Are there variable situations in which the is_private_key_encrypted is sometimes returned as a string; and other times a bool?

My experience is that it's always returned as a bool, as this field is general to all destinations; and thus the existing/published version of that struct is broken.

To recommend using ConfigCustom here seems more of a workaround than a long term fix.

[beevital]

@georgi0u

To recommend using ConfigCustom here seems more of a workaround than a long term fix.

It's not a WA, it's just a common approach that we use.

I agree that is_private_key_encrypted should be marked as bool.
But the problem is that we just don't have enough resources to support this hardcoded mapping - possible config fields set changing constantly, it's just easier to deprecate and remove legacy config from request at all.

[beevital]

And I've just checked and Snowflake returns this field in response as a string, so everything is correct here.

It's not correct on API side for sure, but we can't introduce a type change - it will brake existing contract for existing clients.
This may be fixed in next api contract version only.