Sam Eckert
01/30/2023, 11:21 PM@task
def test(x: int) -> int:
return x + 1
@task
def echo_integer(value: int) -> int:
logging.error(f"I've got value {value}")
return test(x=value + 5) + 1
@workflow
def wf(
value: int,
):
return echo_integer(value=value)
When run locally, we see type-errors because the echo_integer
task now returns a promise instead of an int. Interestingly, it works fine when we run remotely, with the caveat that the called task is not run as a isolated container. I would have expected it to fail remotely as well. Any pointers about what I'm missing in my understanding?Dan Rammer (hamersaw)
01/30/2023, 11:33 PMtask is not run as a isolated container.
so running this how you described means that in remote, when the internal task is called, it's called as a python function rather than the starting a new Pod for a Flyte task. So you could essentially remove the @task
decorator for the same functionality. So the inputs / outputs will not be serialized, that task will not be registered / versioned, the task status' will not be individually viewable, etc.Niels Bantilan
01/30/2023, 11:37 PMKetan (kumare3)
Niels Bantilan
01/30/2023, 11:48 PM@Niels Bantilan / @Dan Rammer (hamersaw) I think the local behaviour should be more consistentSo this means erroring out when calling a task within a task locally, correct?
Ketan (kumare3)
Niels Bantilan
01/30/2023, 11:55 PMSlackbot
01/30/2023, 11:55 PMNiels Bantilan
01/30/2023, 11:56 PMSam Eckert
01/31/2023, 12:41 AMKetan (kumare3)
Sam Eckert
01/31/2023, 12:52 AMNiels Bantilan
01/31/2023, 1:39 AM