https://flyte.org logo
Join Slack
Powered by
Is it possible to loosen the restriction of: The ...
# flyte-support
f
Is it possible to loosen the restriction of: > The input of 
clean_up
should be the exact same as the input of the workflow. > _Source: https://docs.flyte.org/en/v1.14.1/user_guide/development_lifecycle/failure_node.html_ So that Flyte would accept my 
clean_up
function being something like:
Copy code
def my_clean_up(*args, **kwargs): ...
? Any workaround or anything? I'm trying to make a generic cleanup function for our workflows, which have various parameters.
c
@flat-waiter-82487, unfortunately this is part of the design of this feature (the idea being that you'd be able to continue execution in some cases, which forces the interface to be the same). Maybe we can collect a few examples / use-cases and have a discussion about how relaxing the interface might work.
f
It's just the workflow's compiler that complains about the type annotations - in standard Python it would be possible to put 
f(*args, **kwargs)
in place of any callable. I understand type safety checks, but that makes impossible to make generic/shared cleanup function. Any recomendations / workarounds?
Ping @high-accountant-32689
So far, I just did:
Copy code
def my_generic_cleanup(*args, **kwargs):
   ...

def cleanup_for_workflow(actual, params, and, others, with_types):
    my_generic_cleanup(**locals())
But it's ugly and I still have to maintain the signatures between workflow fn and cleanup fn.
h
yeah, unfortunately, in this current version of flyte we don't have plans to augment the failure node feature.
f
What about future plans?
@high-accountant-32689
Ping @high-accountant-32689
h
oh, hey @flat-waiter-82487, sorry for the delay. We should at the very least capture this idea in a gh issue. Can you open one using https://github.com/flyteorg/flyte/issues/new?template=feature_request.yaml ?
2 Views
Open in Slack
PreviousNext
Powered by