Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Failing to materialize a single output of a multi asset fails the whole execution #27943

Open
vladidobro opened this issue Feb 20, 2025 · 0 comments
Labels
type: bug Something isn't working

Comments

@vladidobro
Copy link

What's the issue?

Hello Dagster!

It seems that when a single output of a multi asset fails during HANDLE_OUTPUT, the whole multi asset is aborted.
It seems that there is no way to continue the execution of the multiasset and materialize the other outputs in case one of them fails.

The obvious api would be

@multi_asset(outs={'a': AssetOut(), 'b': AssetOut()})
def mymultiasset(context):
    try:
        yield Output(None, output_name='a')
    except Exception as e:
        context.log.info('except')
        context.log.info(repr(e))
    finally:
        context.log.info('finally')
    context.log.info('after')
    yield Output(None, output_name='b')

but this just logs "finally" and then stops execution.
It seems that the executor is not throwing any errors to the execution function, as the "except" block was not executed.
I have a suspicion that the "finally" block executed only because of the implicit del destructor that generators with "try" or "with" get automatically, not because of dagster orchestration.

In any case, when (and if) the execution gets to the second "yield Output", dagster ignores it completely.

With single-assets, the only usecase for this is resource cleanup, such as

@asset
def myasset(context):
    with resource_that_needs_cleanup:
        yield Output(None)

But here it seems to work well, and the exit function of the context manager is always executed, probably also because of the implicit destructor.

I don't see very much into the internals of dagster, but IMHO the correct behaviour would be to throw the error inside the execution function generator and let it deal with it.

I understand that this is maybe more of a feature request than a bug, but it deviates from what would be naively expected and is undocumented (AFAIK), so I labelled it as a bug. Feel free to relabel it.

What did you expect to happen?

I would expect that the IOManager exception (bare, or wrapped in some IOManagerHandleOutputError(exc)) will be thrown to the asset execution function.
The execution function generator will be resumed with f.throw(exc).
It could decide to handle the error in its own way, optionally continuing to yield other outputs, or simply perform cleanup.
The failed output would be marked as failed.

How to reproduce?

from dagster import *

class IO(ConfigurableIOManager):
    def handle_output(self, context, obj):
        raise ValueError

    def load_input(self, context):
        ...

@multi_asset(
    can_subset=True,
    outs={
        'a': AssetOut(io_manager_key='io', is_required=False),
        'b': AssetOut(),
    }
)
def mymultiasset(context):
    try:
        yield Output(None, output_name='a')
    except Exception as e:
        context.log.info('except')
        context.log.info(repr(e))
    finally:
        context.log.info('finally')
    context.log.info('after')
    yield Output(None, output_name='b')

@asset(io_manager_key='io')
def myasset(context):
    try:
        yield Output(None)
    finally:
        context.log.info('ok')


job = define_asset_job(
    'job',
    [myasset],
)
multijob = define_asset_job(
    'multijob',
    [mymultiasset],
)

defs = Definitions(
        assets=[myasset, mymultiasset],
        jobs=[job, multijob],
        resources={'io': IO()},
)

Dagster version

dagster, version 1.10.1

Deployment type

Local

Deployment details

MacOS arm64

Additional information

No response

Message from the maintainers

Impacted by this issue? Give it a 👍! We factor engagement into prioritization.

@vladidobro vladidobro added the type: bug Something isn't working label Feb 20, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant