Decorated tasks (

@task

) : • Flyte-workflow ↔️ Python-Task ◦ raising

FlyteUserException

in

Python-Task

correctly propagates the exception to workflow. Raw-Containers (

ContainerTask

): • Flyte-workflow ↔️ Raw-Container(ContainerTask) ◦ raising

FlyteUserException

in

Raw-Container

does not propagate the exception to workflow. ◦ the logs do have exceptions raised though. In

ContainerTask

, it only results in a non-zero exit code returned by container. The nuance of python exception

FlyteUserException

is lost between the container and task running the container - which is not surprising as Docker containers are not expected to propagate Python exceptions. So to get around this limitation, we were thinking of then inspecting the logs of container and then raise the same

FlyteUserException

again to be caught by Workflow. For that, we overrode ContainerTask.execute() [link] based on documentation. But what we observed is the overridden method

execute

is not invoked at all. Questions: • for our use case of passing on

FlyteUserException

from a

ContainerTask

to a workflow , do you think overriding

execute

is the way to go? Or is there a better approach? • if overriding

execute

is a good approach, why is our code not working? I have a sample code below that captures what we are attempting.

class CustomContainerTask(ContainerTask):
    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)

    def execute(self, **kwargs) -> LiteralMap:
        client = docker.from_env()
        container = client.containers.run(self.image, self.command)
        if "FlyteUserException" in container:
            raise FlyteException("Exception in execute()")
        return container

Or a better question about writing out

LiteralMap

- isn’t that whats already done in ContainerTask method execute?

That said, we can augment this mechanism to handle user-provided errors in raw containers (by modifying flytecopilot). It's just that this was not implemented yet.