Flag for removing JSON config encoding from the bridge

[t0yv0]

Testing removing JSON config encoding from product I discovered that it is not enough to make a codegen change, because the bridge re-encodes configuration data passed into Check using JSON config encoding even if the data was passed in the plain.

To enable successful rollout, we need to ensure that a bridge release is simultaneously:

1. removing config encoding from all code paths except parsing olds in DiffConfig
2. setting the flag for every affected code generator (Node, Python, Java, C#) to avoid JSON-encoding config properties

Alternatives to doing this:

• engine-mediated feature detection that informs CheckConfig and Configure on whether JSON encoding is used or not by the language SDK
• fix config_encoding to not re-encode unless it believes the data was JSON-decoded in the first place

[iwahbe]

What's the criteria of a successful rollout? Is the goal to allow users to see no diff on the rollout, or just to avoid breaking the user?

If the goal is simply to avoid breaking the user, could we:

1. Prevent the bridge re-encoding the config in CheckConfig, so new provider state is saved without JSON encoding.
2. Rollout (per language, independent from the bridge) the change to not JSON encode config (assuming this is correctly handled by the bridge now).
3. When all languages have stopped JSON encoding their config, add a warning when the bridge detects JSON encoded config coming from anywhere but state (via DiffConfig or Configure).

I have no issue believing that ☝ is non-viable, but I don't understand why.

From your description, it seems like setting config_encoding to not re-encode in all cases is unsafe, can you explain why?

[t0yv0]

Can consider. Let's try this out and see how it plays out. I would love to decouple the rollout constraints. This can be a good option Along with fix config_encoding to not re-encode unless it believes the data was JSON-decoded in the first place.

I have some uncertainty about detecting the encoding from the data and trying to make that transparent, does "true" encode true or "true"? Does [] encode an empty list or a string "[]"? skipMetadatApiCheck issues are slightly different but tangentially related here.