crooked-artist-67935
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?hallowed-mouse-14616
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.broad-monitor-993
01/30/2023, 11:37 PMfreezing-airport-6809
freezing-airport-6809
broad-monitor-993
01/30/2023, 11:48 PM@broad-monitor-993 / @hallowed-mouse-14616 I think the local behaviour should be more consistentSo this means erroring out when calling a task within a task locally, correct?
freezing-airport-6809
freezing-airport-6809
freezing-airport-6809
freezing-airport-6809
broad-monitor-993
01/30/2023, 11:55 PMuser
01/30/2023, 11:55 PMbroad-monitor-993
01/30/2023, 11:56 PMbroad-monitor-993
01/30/2023, 11:58 PMcrooked-artist-67935
01/31/2023, 12:41 AMcrooked-artist-67935
01/31/2023, 12:44 AMfreezing-airport-6809
freezing-airport-6809
crooked-artist-67935
01/31/2023, 12:52 AMbroad-monitor-993
01/31/2023, 1:39 AMbroad-monitor-993
01/31/2023, 1:57 AM