[Bug]: `--shard` silently disables `--tia` — the shard is rewritten to `--filter`, which counts as a partial run

What Happened

--shard and --tia cannot be combined. A sharded run silently disables TIA and reports it as user error.

Shard::handleArguments() resolves the shard and appends a generated class-name regex as --filter (src/Plugins/Shard.php:161):

return [...$arguments, '--filter', $filter];

--filter is a member of Tia::PARTIAL_SELECTION_FLAGS (src/Plugins/Tia.php:135-140):

private const array PARTIAL_SELECTION_FLAGS = [
    '--filter', '--exclude-filter', '--group', '--exclude-group',
    ...
];

so Tia::handleArguments() → hasPartialSelection() sets $disabled = true, and the run prints:

  ─ TIA does not apply to partial runs — running the selected tests directly.

The user never passed a selection flag — Pest generated one internally — so the message describes a state the invocation did not ask for. Sharding partitions the suite; it does not narrow it by intent the way --filter or --group does, and each shard is a complete, deterministic slice whose tests TIA could replay normally.

--exclude-group is in the same list and disables TIA independently. That matters for the recording side too: a baseline run of the form pest --tia --fresh --exclude-group=slow records no dependency graph at all, and the only signal is the same one-line notice.

Net effect: TIA is unusable in sharded CI, which is the setup that stands to gain the most from it. The interaction is invisible unless someone reads that line in the log — the run is otherwise green and simply slower than expected.

How to Reproduce

On a repo with a recorded TIA graph:

vendor/bin/pest --tia --parallel --shard=1/6 --stop-on-defect

No --filter, --group or --exclude-group is passed. Observed output:

  ─ TIA does not apply to partial runs — running the selected tests directly.

Dropping --shard makes TIA engage normally against the same graph.

Expected: TIA applies within the shard's slice — replaying unaffected tests in that slice and executing the affected ones — rather than switching itself off.

Verified on our CI (6 shards, self-hosted Linux runners) with an instrumented job that seeds a known-good baseline and then runs the shard command with and without --exclude-group; both variants print the notice, so --shard alone is sufficient to trigger it.

Pest Version

v5.0.4

PHP Version

8.4

Operation System

Linux (Ubuntu container, self-hosted GitHub Actions runner)

Notes

Possible directions, in case any is closer to intent than the others:

1. Have Shard communicate the slice to Tia out of band rather than through --filter, so hasPartialSelection() never sees it.
2. Exempt a shard-generated filter from hasPartialSelection() — e.g. mark the argument as internally generated when Shard appends it.
3. Treat sharding as compatible by design: partition first, then let TIA replay within the partition.

Related but distinct: #1722 (count-based --shard fallback and --filter PCRE limits) documents the same --filter rewrite from the sharding side. #1791 covers --tia not being recognised depending on option order. I could not find an existing report of the shard/TIA interaction itself.

Happy to open a PR if you can indicate which direction you'd prefer.

Start by reading src/Plugins/Shard.php around handleArguments() and src/Plugins/Tia.php around PARTIAL_SELECTION_FLAGS and handleArguments(). Trace how the generated --filter reaches hasPartialSelection(), then determine how sharding can remain distinguishable from user-selected partial runs. Done means --tia applies within each --shard slice, including with --exclude-group, without the partial-run notice; verify with the reproduction command and a recorded TIA graph.