Launchpad requires credential config for ADLS2Resource when using ADLS2DefaultAzureCredential(kwargs={}), but execution works without it

[gordersam]

What's the issue?

When configuring ADLS2Resource with ADLS2DefaultAzureCredential(kwargs={}), assets execute successfully; however, the Launchpad UI reports a schema error saying the required credential config is missing. If any key/value is placed in kwargs (even a dummy one), the Launchpad error disappears.

What did you expect to happen?

With credential=ADLS2DefaultAzureCredential(kwargs={}), Launchpad should not report credential as missing, because the credential has been provided programmatically and the asset run succeeds.

How to reproduce?

1.	Define ADLS2Resource with credential=ADLS2DefaultAzureCredential(kwargs={}).
2.	Reference the resource in an asset.
3.	Open the asset in Launchpad → observe the “Missing required config entry credential …” error.
4.	Change to kwargs={"a": "a"} (or any non-empty mapping).
5.	Reopen Launchpad → error disappears.

Dagster version

dagster, version 1.11.12

Deployment type

None

Deployment details

No response

Additional information

No response

Message from the maintainers

Impacted by this issue? Give it a 👍! We factor engagement into prioritization.

[zyd14]

I was curious to take a crack at this as on the surface it seems pretty simple. I was able to reproduce this, but interestingly it seems to only be a problem when the launchpad first opens up for assets because the default config is automatically scaffolded for assets. It seems that with how Dagster represents discriminated unions under the hood results in config attributes that are discriminated unions not being scaffolded alongside the rest of the non-discriminated union attributes. But the validation error goes away if the configuration for the ADLS resource is removed entirely - so for op-jobs where default config doesn't appear to be automatically scaffolded no validation error appears, unless the config is scaffolded (or you try to configure an attribute on the resource).

I'll dig into this a bit further, I think the root question at hand is why defaults for discriminated union attribute don't get scaffolded along with the rest of the attribute. I'm not super confident I'll find a solution, particularly if this crosses over into UI territory as I'm not particularly familiar with React. So if someone else who's more familiar with that wants to dig into this feel free to take over.