`dvc repro`: dvc.lock records dependency hashes from after cmd finishes, allowing the recorded code↔output linkage to be falsified

[TimOliverMaier]

Bug Report

Description

Hello,

I discovered today that with dvc repro of a pipeline the hash sums of a stage's dependency
are calculated and stored after execution. Which lets DVC record a false code <-> output linkage,
if a dependency is changed mid-run.

Reproduce

In a DVC repository place a file e.g. bar.py

from time import sleep

param = 20
sleep(param)

with open("bar_output.txt", "w") as f:
    f.write(f"Bar completed after {param} seconds\n")

and the simple dvc.yaml:

stages:
  bar:
    cmd: python bar.py
    deps:
      - bar.py
    outs:
      - bar_output.txt

Now go through the following steps

(0. dvc init if not initialized yet)

1. dvc repro
2. change param in bar.py to something else while file executes
3. rerun dvc repro after pipeline has finished

The pipeline will not be executed, even though the file has changed. The altered code
is hence linked to the pipeline output of the original code.

Expected

I know that this is sort of an edge case. Nevertheless I personally assumed the hash values were calculated before the stage is executed.

Environment information

OS: CachyOS
Python env: installed with uv
python version: 3.13.12
dvc version: 3.67.1

Output of dvc doctor:

DVC version: 3.67.1 (pip)
-------------------------
Platform: Python 3.13.12 on Linux-7.1.2-3-cachyos-x86_64-with-glibc2.43
Subprojects:
        dvc_data = 3.18.3
        dvc_objects = 5.2.0
        dvc_render = 1.0.2
        dvc_task = 0.40.2
        scmrepo = 3.6.2
Supports:
        azure (adlfs = 2026.5.0, knack = 0.14.0, azure-identity = 1.25.3),
        gdrive (pydrive2 = 1.21.2),
        gs (gcsfs = 2026.6.0),
        hdfs (fsspec = 2026.6.0, pyarrow = 24.0.0),
        http (aiohttp = 3.14.1, aiohttp-retry = 2.9.1),
        https (aiohttp = 3.14.1, aiohttp-retry = 2.9.1),
        oss (ossfs = 2025.5.0),
        s3 (s3fs = 2026.6.0),
        ssh (sshfs = 2025.11.0),
        webdav (webdav4 = 0.11.0),
        webdavs (webdav4 = 0.11.0),
        webhdfs (fsspec = 2026.6.0)
Config:
        Global: /home/tim/.config/dvc
        System: /etc/xdg/dvc
Cache types: reflink, hardlink, symlink
Cache directory: btrfs on /dev/nvme1n1p2
Caches: local
Remotes: None
Workspace directory: btrfs on /dev/nvme1n1p2
Repo: dvc, git
Repo.site_cache_dir: /var/tmp/dvc/repo/9df4aa3c978d01a1af9e0e982551cb0b

Is this a bug or is there a reason for this behavior ?
Thank you for your help and advice on this!

Best
Tim

[ChetanyaRathi]

I looked into this a bit more and I think I understand why it happens.
When dvc repro runs a stage, DVC calculates the dependency hashes after the command finishes, not before. So if a dependency file is changed while the command is still running, DVC stores the hash of the new file in dvc.lock. But the output was actually made from the old file. The lock now points to the wrong version.
That is why the second dvc repro skips the stage: the file on disk matches the hash in dvc.lock, so DVC thinks nothing changed.
I think the fix is:

calculate and store the dependency hashes before running the command
after the command finishes, check if any dependency changed during the run. If it did, keep the pre-run hash and print a warning.

This way the lock always matches the inputs that really produced the output. And if a dependency is changed mid-run, the stage will correctly show as "changed" on the next run instead of being skipped.
I'm happy to open a PR for this if it sounds good.

[TimOliverMaier]

Hi @ChetanyaRathi

Yes that's how I understood the issue, as well. The fix sounds good to me. Thank you for working on that!

[ChetanyaRathi]

Thanks for confirming, @TimOliverMaier! Glad we're on the same page. The fix is up in #11062 and all checks are passing — just waiting on a maintainer review now.