so, i've been poking a lot around

[mossy bay]

context: https://github.com/dagger/dagger/blob/843f2c52fe3618724f75eb30cf108a5e1c7c500f/core/typedef.go#L85-L109
i'm wanting to fully decode the "default" value provided by the module. atm, we're actually deferring most of the real operation, which actually means you can provide invalid default values which is fine as long as you never call it (this seems bad).
but, to actually do the operation here, we need to fully resolve the typedef of the arg, so we get the full definition.

kinda hoping @reef dome you might a suggestion for where this makes the most sense? i can get it working, by making an introspection query everytime i call ModTypeFor, but this doesn't seem right

[reef dome]

Just looked briefly so far, but yeah I agree definitely don't want to run a full introspection query each time there.

I guess I'm surprised that the typedefs returned by ModTypeFor are "incomplete references". AFAICT we only append to e.g. Module.EnumDefs in the corresponding API like withEnum (https://github.com/sipsma/dagger/blob/1f3079a235d0c93812e43e34fbc03eac21ca17c1/core/module.go#L793-L793)

And then ModTypeFor iterates over that list to return the typedef (https://github.com/dagger/dagger/blob/bc8db1d4de6136f9a934705784c1d3982d9b21fb/core/module.go#L360)

So are SDKs making top level calls like withEnum on the module with "incomplete references"? If so, I'm surprised

Sorry not super helpful yet, just making sure I'm understanding the problem

Generally speaking I agree that ModTypeFor should return the fully resolved typedef, not a stub reference

[mossy bay]

the user modules work as intended - it's coremod that has an issue, because it just directly returns the typedef from the param

(there was a slight issue with nullable user types not being quite right, but I've fixed that one in my branch)

[reef dome]

Ah okay, missed that it was just core. In that case, we probably just need to re-arrange some of the code in CoreMod to do the introspection only once and then just always re-use that result in ModTypeFor, right? So just saving the "fully hydrated" typedefs (as calculated in CoreMod.TypeDefs) in a field on the CoreMod struct and then using those in ModTypeFor

Honestly we could just only run that once engine-wide, though probably a bigger out-of-scope change than what you want right now