Alex Suraci

Shower thought tier analysis: It seems like our module test suite spends a ton of time calling `dagger init` in each test, downloading the same dependencies and building the same...

@shykes @marcosnils I implemented a minimal API for error returns from functions. It was either that or keep doing janky workarounds so I figured I'd take a swing at it...

Current status: sitting on this for a bit since I'd like its release to coincide with switching Cloud trace UI over to WASM, and there's a bit more work to...

@sipsma This should be good to go. There's more polish I could do but I think this PR has gone long enough at this point. 😅 Probably worth pointing out...

@nipuna-perera Proxy env vars are a great point to bring up, but I think they should be treated as an exceptional case. I definitely don't think module authors should ever...

Half baked thought: we actually don't even have a nice way for functions to return errors at the moment. If you return an error in the Go SDK that just...

A bikeshedding opportunity emerges: * https://github.com/dagger/dagger/pull/8442#issuecomment-2353402147 MVP API: ```graphql type Query { # Construct an Error value to be returned by a function. error(message: String!): Error! } type Error {...

@TomChv I like the last option the most - assuming that's the closest to how errors would normally be used in TypeScript. Same for Python I figure; each SDK runtime...

@MatthiasGrandl Hi! Would you mind providing a few details on your use case? There's been _some_ progress depending on what you're after. Namely, our `Error` API type supports having arbitrary...

@shykes Maybe there's an opportunity to allow typed values to be _bound_ to an `Error` just like they can be bound to an `Env`? 🤔 (context: https://github.com/dagger/dagger/discussions/10370)