[BUG] Flyteadmin treats workflow compilation failures as internal

[katrogan]

Describe the bug

Flyteadmin currently returns grpc status Internal for workflow compilation failures:

flyte/flyteadmin/pkg/manager/impl/workflow_manager.go

Lines 145 to 151 in 4f6c54b

	// Validate that the workflow compiles.
	workflowClosure, err := w.getCompiledWorkflow(ctx, finalizedRequest)
	if err != nil {
	logger.Errorf(ctx, "Failed to compile workflow with err: %v", err)
	return nil, errors.NewFlyteAdminErrorf(codes.Internal,
	"failed to compile workflow for [%+v] with err %v", request.Id, err)
	}

Expected behavior

An invalid workflow passed into the create request should be treated as a user rather than server error

Additional context to reproduce

No response

Screenshots

No response

Are you sure this issue hasn't been raised already?

• Yes

Have you read the Code of Conduct?

• Yes

[dosubot]

🤖

Hey @katrogan!👋 I'm Dosu, a friendly bot here to assist you while we wait for a human maintainer to join us. I'm designed to help solve bugs, answer questions, and assist you in becoming a contributor. Let's dig into this together, shall we? 😊

I understand your concern about Flyteadmin treating workflow compilation failures as internal server errors rather than user errors. This behavior is due to the fact that the compilation process is considered a server-side operation. The server is responsible for compiling the workflow, and if it fails, it's treated as a server error. This is evident in the TestCreateWorkflow_CompileWorkflowError function in the workflow_manager_test.go file.

The workflow compilation process in Flyteadmin involves several steps, including validation of inputs, task validation, workflow requirements validation, workflow validation, and finally, compilation. If any of these steps fail, it's considered a server error because these operations are performed by the server. You can find more details about the workflow compilation process in the CompileWorkflow function in the workflow_compiler.go file.

Additionally, there are other error types in Flyteadmin that are treated as server errors when they could be considered user errors. For instance, all Gorm errors, except for gorm.ErrRecordNotFound, are treated as server errors (codes.Internal). This includes errors that could be due to user input, such as invalid query parameters. Similarly, all PgErrors, except for uniqueConstraintViolationCode and undefinedTable, are treated as server errors (codes.Unknown). This includes errors that could be due to user input, such as invalid SQL syntax or non-existent table/column names. You can find more details about this in the fromGormError and ToFlyteAdminError functions in the postgres.go file.

I hope this clarifies why Flyteadmin treats workflow compilation failures as internal server errors. If you have any further questions, feel free to ask.

Sources

• flyteadmin/pkg/manager/impl/workflow_manager_test.go
• flytepropeller/pkg/compiler/workflow_compiler.go
• flyteadmin/pkg/repositories/errors/postgres.go

---

This response is meant to be useful and save you time. It is not meant to be a precise solution, but rather a starting point for your own research.

Help me be more useful! Please leave a 👍 if this is helpful and 👎 if it is irrelevant.

If you want to continue the conversation, start your reply with @dosu-bot.