vp run can execute the same dependency task in parallel via nested vp run

[SegaraRai]

Summary

vp run can execute the same dependency task in parallel when sibling tasks invoke nested vp run commands.

Within a single top-level vp run, the same logical dependency task may be planned independently by multiple nested runs and started at the same time.

Minimal repro

Repo: https://github.com/SegaraRai/vitetask-repro01

Relevant task structure:

• shared is a normal task
• unit:a and unit:b both depend on shared
• control depends directly on unit:a and unit:b
• parallel:a runs vp run unit:a
• parallel:b runs vp run unit:b
• parallel depends on parallel:a and parallel:b

Parallel repro steps

vp install
vp run clean
vp run build:parallel

Then inspect build.log.

Observed behavior

@repro/app-a:shared starts twice almost at the same time.

Example from build.log:

START 2026-... @repro/app-a:shared ...
START 2026-... @repro/app-a:shared ...
END   2026-... @repro/app-a:shared ...
END   2026-... @repro/app-a:shared ...

So this is not just duplicate execution across the overall run. It is the same dependency task being executed concurrently.

Expected behavior

@repro/app-a:shared should be executed once for the top-level run.

At minimum, the same logical task should not be started concurrently multiple times.

Control case

This does not reproduce the issue:

vp run clean
vp run build:control

In that case, control -> [unit:a, unit:b] is expressed directly in one execution graph, and shared runs only once.

So the issue seems specifically related to nested vp run invocations, especially when those nested runs are themselves reached from sibling tasks that can execute in parallel.

Additional note

The same repo also includes a sequential nested case:

vp run clean
vp run build:nested

That also causes duplicate execution, but the more serious problem is the parallel case above, where the same task is started concurrently.

Why this matters

In real projects this can cause:

• duplicated expensive work
• races on shared outputs or generated files
• nondeterministic build failures

In my original project, this appeared to cause exactly that kind of build instability.

Version

Observed with:

• vite-plus 0.1.16 (Windows)

[SegaraRai]

If full task de-duplication is hard to implement, some form of task-level mutual exclusion would still help a lot.

It would not remove the redundant work, but it would avoid the more serious problem here: the same logical task running concurrently and racing on shared outputs or generated files.