New RunLLM response generated: >>>*# Question* I am developing a workflow that has two levels of fan out. I get a list[list[str]] and need to produce a list[list[FlyteDirectory]]. This is done by using two levels of map_task . Everything works fine locally but when executing remotely, I get this error:

USER:AssertionError: error=Expected a directory, but the given uri '/tmp/flyte-9lq_c257/sandbox/local_flytekit/44d6ea3a6ffa4d930e874e79131e4c3fimsop046/tmphwg8139l' is not a directory.

The funny thing is that I don't get this error if I only have one level of map_task nor do I get this if I avoid using map_task and use two layers of dynamic tasks. Is this expected? I have a few observations: • The problem gets resolved if my innermost task returns a path String and lets Flyte create FlyteDirectory rather than constructing FlyteDirectory itself • The path pattens seem to be different when using one level of map_task and two levels ("/tmp/flytearog1v2o/control_plane_metadata/local_flytekit/..." vs "/tmp/flyte-9lq_c257/sandbox/local_flytekit/..." Here is the code for the inner most task

@task(retries=0)  # type: ignore [misc]
def dummy_task(input: str) -> FlyteDirectory:
    working_dir = current_context().working_directory
    local_dir = Path(tempfile.mkdtemp(dir=working_dir))
    out_path = local_dir / "test.txt"
    abs_path = out_path.absolute()
    with abs_path.open("w") as f:
        f.write(input)

    # This fails remotely
    return FlyteDirectory(str(local_dir.absolute()))
    # But this succeeds!
    # return str(local_dir.absolute())

# Answer The issue you're encountering with

FlyteDirectory

in a nested

map_task

setup is related to how Flyte handles directory paths and serialization. When using

map_task

, Flyte expects the returned

FlyteDirectory

to be properly serialized and accessible remotely, which seems to be failing in your case. Observations: 1. Path Patterns: The difference in path patterns indicates that the directory paths are being handled differently in nested

map_task

scenarios. 2. Returning Path String: Returning a path string and letting Flyte create the

FlyteDirectory

works because Flyte handles the serialization and remote accessibility of the directory. Workaround: To avoid this issue, you can return the path string from your innermost task and let Flyte handle the creation of the

FlyteDirectory

. This ensures that the directory is correctly serialized and accessible remotely. Example Code: