You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
ContainerCodeExecutor drops output files that are hard links #7906
ContainerCodeExecutor (input/output files added in effd641) returns only the first name when the executed code leaves two hard-linked names in the output directory, for example after os.link("a.csv", "b.csv") or cp -l. The second file is silently missing from CodeExecutionResult.output_files.
Docker's get_archive writes the second path to an inode it has already archived as a hard-link entry (type LNK, size 0), as Python's tarfile.add does. _extract_output_files keeps only entries where member.isfile() is true, and that is false for link entries.
src/google/adk/code_executors/container_code_executor.py, in _extract_output_files:
formemberintar.getmembers():
ifmember.isfile():
To Reproduce
The repro builds the archive from a real directory with tarfile, as Docker would return it, and feeds it to the executor through a mocked container, the same way tests/unittests/code_executors/test_container_code_executor.py does.
tar.extractfile() already resolves a hard-link member to its target's data inside the archive, so no other change is needed. Plus a regression test that builds the archive from a directory containing a hard link.
Question (separate, smaller)
CodeExecutorContext.add_input_files() only appends. If code adds data.csv in one turn and an updated data.csv in a later turn, every later execution fails with ValueError: Duplicate input file name: 'data.csv', and since the list lives in session state the session can't recover. The flow's own inline-file path avoids this by skipping known names. Should add_input_files replace an existing file with the same name, or is the error intended?
I can open a PR for the hard-link fix if that's welcome.
Desktop (please complete the following information):
I've reproduced the hard-link issue and tested a minimal fix that accepts TarInfo.islnk() alongside regular files.
I added a regression test using a mocked Docker archive that verifies both hard-linked filenames retain their content and symbolic links remain excluded.
I noticed you offered to open a PR. Are you planning to work on it? If so, I don't want to duplicate your effort. Otherwise, I'd be happy to contribute the tested fix.
Activity
OKAN-SOFTWARE commentedon Oct 31, 2026
I've reproduced the hard-link issue and tested a minimal fix that accepts
TarInfo.islnk()alongside regular files.I added a regression test using a mocked Docker archive that verifies both hard-linked filenames retain their content and symbolic links remain excluded.
Validation: 41 passed, 6 skipped (Windows-specific skips). Ruff, isort, Pyink, and whitespace checks passed.
I noticed you offered to open a PR. Are you planning to work on it? If so, I don't want to duplicate your effort. Otherwise, I'd be happy to contribute the tested fix.
AkshayShah03 commentedon Nov 1, 2026
Thanks for picking it up — go ahead and open the PR. I'm focusing on #7905, so happy to review yours when it's up.