Traces: function error message not shown

[shykes]

Context

In Traces, function calls are shown with information about their status:

• If the function returned an error, it's shown in red
• The error message is displayed in a special box - at least in theory

Problem

The error message shown in the box is not the one actually returned by the function. Instead, it's always the same generic, and useless, message:

call function "Foo": process "/runtime" did not complete successfully: exit code: 2

Solution

Use the existing "error box" to show the actual error returned by the function, instead of the generic "exit code: 2" error.

[jedevc]

@shykes is there an issue in the engine/cli/sdks here? Sorry, I'm not sure.

[vito]

This is in core:

dagger/core/modfunc.go

Lines 254 to 261 in a218fef

	_, err = ctr.Evaluate(ctx)
	if err != nil {
	if fn.metadata.OriginalName == "" {
	return nil, fmt.Errorf("call constructor: %w", err)
	} else {
	return nil, fmt.Errorf("call function %q: %w", fn.metadata.OriginalName, err)
	}
	}

Here are two competing proposals to kickstart the conversation:

• Just capture stderr and return it as the error message, ungarnished (no wrapping). This would be super easy for SDK authors to implement (Go SDK pattern already matches it), also feels like a sane fallback if something blows up unexpectedly (i.e. panic()).
• Add a Function.returnError API that just takes a string arg. This would be more explicit than above, but SDK authors would have to implement it. This might be more sane for SDKs like Python that print an entire stack trace.

I started with the first point as a quick hack, but now I'm leaning towards the second option, since you'll always have logs to see more details.

There's further temptation to have something like Function.returnErrorReport for linters. Arguably that should instead be a structured return value, but the catch is that if you do a regular return value the call won't have failed, which is the whole point of a linter. So it seems there's some merit to the idea of returning some sort of error structure, but I don't know what it should be. Maybe a problem for another day.