Dagger terminal stuck

[zenith bramble]

I have dagger engine running on a VM. From my laptop I am connecting to the docker container (dagger-engine) via _EXPERIMENTAL_DAGGER_RUNNER_HOST=tcp://1.2.3.4:1234 I wanted to debug a dagger module so I added .terminal() and after exiting, it looks like the terminal is stuck. The last step is exporting the directory, the directory has been exported but the terminal is still a non-responsive state.
Looking at the dagger-engine logs and I do not see anything indicating an error.

It's been in this state for the last 30 minutes.

After hitting Ctrl-C, I see this:

[placid snow]

👋 IIUC your module functions returns a Directory, correct? And you're adding a Terminal call right before that?

cc @fading path

just checking.. what SDK are you using?

[zenith bramble]

That is correct.
i am using Python SDK

[placid snow]

doing a test really quick. Just checking again, are you using v0.12.7?

@zenith bramble just did a quick test and seems to be working fine for me. Can you check if this simple example works for you?

    def test(self) -> dagger.Directory:
        """Returns a container that echoes whatever string argument is provided"""
        return (
            dag.container()
            .from_("alpine:latest")
            .with_new_file("/app/foo", "bar")
            .terminal()
            .directory("/app")
        )

what I think is happening is that the export is taking way too much time in your case for some reason and the output just gets stuck there

after you exit a terminal debugging session, you won't see any fruther output until the pipeline finishes

that's beacuase we currently don't support a way of resuming the initial DAG output

[zenith bramble]

let me try.
I am using version 0.12.5 for the CLI and the engine.

[zenith bramble]

so the example above worked fine. even with using dagger engine on remote vm

i am still having issues with this, expecially if the previous command took 30mins to finish (mvn compile)

it seems to download half the internet and then i have the container.terminal() command and it takes a few seconds for the terminal to start.
after i exit, the terminal UI is un-responsive.

However, i see the directory has been created with some contents in it

[placid snow]

@zenith bramble are you sure you're exporting only what you need?

maybe you're also downloading all the dependencies that mvn installed in the container?

[zenith bramble]

i am only exporting my /code dir.
as i have set that to my working directory.

Here is my final return code:

                    git_container
                    .with_mounted_directory("/code", snapshot_dir)
                    .with_workdir("/code")                
                    .with_exec(["git", "add", "-u"])
                    .with_exec(["git", "commit", "-m", f"Updating version -- {next_snap_version}"])
                    .directory("/code")
                  )
        return await git_dir

then when i all this pipeline:
dagger -m my-mod call foo-pipeline export --path local-dir --wipe

[placid snow]

can you run du -sh /code before the .directory("/code") to check how big the folder is?

[zenith bramble]

once the terminal command is executed?
ie: when i am in the terminal?

so, without using terminal command, the directory outputs and finishes fine:

1.2G    florkin

restarting the pipeline.
i will report what the size is in the container (after terminal is execued)

[placid snow]

so yeah.. it seems to be downloading 1.2G from the remote engine

if that's over internet, it might take some time

[zenith bramble]

okay -- understood.
it's okay that it takes time.

but after exiting the terminal command, it seems like the process is stuck.

[placid snow]

it'll get "stuck" until it finishes downloading the 1.2G and it should unstuck once that finishes

[zenith bramble]

got it.
in the rush to try out the example, i didn't completely read the text:

after you exit a terminal debugging session, you won't see any fruther output until the pipeline finishes
that's beacuase we currently don't support a way of resuming the initial DAG output

so i understand.
answer is to wait it out

thank you @placid snow for your patience and help

[placid snow]

sure, np