force repro updates hashsums of frozen stages' dependencies

[TimOliverMaier]

Hi!

I posted this into discussions yesterday, but after some feedback from coworkers today decided to put this out as an issue, as DVC shows (at least in our eyes) rather unexpected behavior.

I recently realized that running dvc repro -f updates the dependencies of frozen stages in dvc.lock. dvc repro without force does not. Is that intended? If so, why? Personally, I would expect dvc.lock to list the dependency's hashsum as it was when the stage was produced?

A minimal example to reproduce the issue:

dvc.yaml:

stages:
  first_stage:
    cmd: python foo.py
    deps:
    - foo.py
  second_stage:
    cmd: python bar.py
    deps:
    - bar.py
    - foo.py

foo.py:

print("foo")

bar.py:

print("bar")

1. dvc repro
2. dvc freeze second_stage
3. change foo.py and run dvc repro -> deps of second_stage do not change in dvc.lock
4. run dvc repro -f -> deps of second_stage change

Thank you for your help. I used DVC at 3.66.1

output of dvc doctor

DVC version: 3.66.1 (pip)
-------------------------
Platform: Python 3.10.12 on Linux-6.8.0-94-generic-x86_64-with-glibc2.35
Subprojects:
	dvc_data = 3.18.2
	dvc_objects = 5.2.0
	dvc_render = 1.0.2
	dvc_task = 0.40.2
	scmrepo = 3.6.1
Supports:
	http (aiohttp = 3.13.3, aiohttp-retry = 2.9.1),
	https (aiohttp = 3.13.3, aiohttp-retry = 2.9.1)
Config:
	Global: /home/tim/.config/dvc
	System: /etc/xdg/xdg-ubuntu/dvc
Cache types: <https://error.dvc.org/no-dvc-cache>
Caches: local
Remotes: None
Workspace directory: ext4 on /dev/nvme0n1p2
Repo: dvc, git
Repo.site_cache_dir: /var/tmp/dvc/repo/7356c608e149ca636a5b0c11cf73fc9b

Best
Tim

Originally posted by @TimOliverMaier in #11000

[skshetry]

Hi, you are right that we should not reproduce frozen stages even on --force. Even the docs in the dvc freeze explicitly states (emphasis mine):

Stage reproduction will not regenerate outputs of frozen stages, even if their dependencies have changed, and even if --force is used.

However, I tested this up to the 1.1.x versions of DVC, and it doesn’t seem to respect this behavior anywhere.

[TimOliverMaier]

Hi @skshetry ,

Thank you for looking into this! I had Claude look into this issue and I think it identified the problem and found a good fix.

First the problem:

It seems the method reproduce from class Stage just passes to run method if force==True

dvc/dvc/stage/__init__.py

Lines 419 to 452 in dcf6f48

	@rwlocked(read=["deps"], write=["outs"])
	def reproduce(self, interactive=False, **kwargs) -> Optional["Stage"]:
	force = kwargs.get("force", False)
	allow_missing = kwargs.get("allow_missing", False)
	pull = kwargs.get("pull", False)
	upstream = kwargs.pop("upstream", None)
	if force:
	pass
	# Skip stages with missing data if otherwise unchanged
	elif not self.changed(allow_missing, upstream):
	if not isinstance(self, PipelineStage) and self.is_data_source:
	logger.info("'%s' didn't change, skipping", self.addressing)
	else:
	logger.info("Stage '%s' didn't change, skipping", self.addressing)
	return None
	# Pull stages with missing data if otherwise unchanged
	elif not self.changed(True, upstream) and pull:
	try:
	logger.info("Pulling data for %s", self)
	self.repo.pull(self.addressing, jobs=kwargs.get("jobs"))
	self.checkout()
	return None
	except CheckoutError:
	logger.info("Unable to pull data for %s", self)
	msg = f"Going to reproduce {self}. Are you sure you want to continue?"
	if interactive and not prompt.confirm(msg):
	raise DvcException("reproduction aborted by the user")
	self.run(**kwargs)
	logger.debug("%s was reproduced", self)
	return self

Claude now recommended these changes:

    @rwlocked(read=["deps"], write=["outs"])
    def reproduce(self, interactive=False, **kwargs) -> Optional["Stage"]:
        force = kwargs.get("force", False)
        allow_missing = kwargs.get("allow_missing", False)
        pull = kwargs.get("pull", False)
        upstream = kwargs.pop("upstream", None)
+       # Frozen stages should never be reproduced, even with --force.
+       # Without this check, `dvc repro -f` would update dependency hashes
+       # in dvc.lock for frozen stages without actually re-running them.
+       if self.frozen and not self.is_import:
+           if not isinstance(self, PipelineStage) and self.is_data_source:
+               logger.info("'%s' didn't change, skipping", self.addressing)
+           else:
+               logger.info("Stage '%s' didn't change, skipping", self.addressing)
+           return None
        if force:
            pass
        # Skip stages with missing data if otherwise unchanged
        elif not self.changed(allow_missing, upstream):
            if not isinstance(self, PipelineStage) and self.is_data_source:
                logger.info("'%s' didn't change, skipping", self.addressing)
            else:
                logger.info("Stage '%s' didn't change, skipping", self.addressing)
            return None
        # Pull stages with missing data if otherwise unchanged
        elif not self.changed(True, upstream) and pull:
            try:
                logger.info("Pulling data for %s", self)
                self.repo.pull(self.addressing, jobs=kwargs.get("jobs"))
                self.checkout()
                return None
            except CheckoutError:
                logger.info("Unable to pull data for %s", self)

        msg = f"Going to reproduce {self}. Are you sure you want to continue?"
        if interactive and not prompt.confirm(msg):
            raise DvcException("reproduction aborted by the user")

        self.run(**kwargs)

        logger.debug("%s was reproduced", self)

        return self

I reviewed this and for me it makes sense - maybe the logger message should be changed to inform that this stage is skipped because its frozen. But the place where this check is put makes sense to me.
Let me know if you think that this is a sensible way to go, I am happy to open a PR.

Cheers!