Thomas Gummerer 8c86831bc9 resolve providers in the engine before running transforms (#16409) ... We're considering whether it makes sense to document setting "default providers" through transforms. For that we want to make sure the transforms behave exactly the way we expect before trying to document anything, and going ahead with that plan. Currently it is the SDKs responsibility to resolve the providers map and to resolve the parent relationship and send the provider in a resolved manner to the engine. For example in the NodeJS SDK this currently happens here: 91568bc03b/sdk/nodejs/resource.ts (L445-L469) To make sure this works in the same way in every SDK, and that we can add an engine test to make sure this works consistently, we add the same resolution of the provider before we pass these options to the transform. We'll keep the resolution in the SDK, which will be preferred (we'll choose the Provider resource option first in any case), but now also have a fallback to the same extend in the engine. Also add a test to show the behaviour is correct to the engine.		2024-06-21 08:55:17 +00:00
..
diff.stderr.txt	resolve providers in the engine before running transforms (#16409)	2024-06-21 08:55:17 +00:00
diff.stdout.txt	resolve providers in the engine before running transforms (#16409)	2024-06-21 08:55:17 +00:00
eventstream.json	resolve providers in the engine before running transforms (#16409)	2024-06-21 08:55:17 +00:00
progress.stderr.txt	resolve providers in the engine before running transforms (#16409)	2024-06-21 08:55:17 +00:00
progress.stdout.txt	resolve providers in the engine before running transforms (#16409)	2024-06-21 08:55:17 +00:00