process: two implementations of #3164 both merged (#3166, #3167) - every duplicate key missed the pair, and the obvious fix to that key measures as boilerplate

[cagataycali]

One finding, two merged implementations. #3164 said the required suite runs under -x, so a red check names one failure of an unknown number. Both of these landed for it, 50 minutes apart:

pull request	merged	squash	what it adds
#3167	2026-09-03T03:35Z-ish	cd095d6	tests/session_truncation.py + a pytest_configure hook in tests/conftest.py - an in-process terminal-summary section
#3166	2026-09-03T04:25Z	b8c237a	scripts/report_truncated_test_run.py + a test-lint.yml step - parses the log, writes the job summary and an annotation

#3166 carries Closes #3164; #3167 says Refs #3164. So the issue is closed and the pair is invisible from it.

Why all four duplicate keys missed it

Measured against the keys AGENTS.md > PR Workflow step 1 documents:

key	why it was silent
claim (closingIssuesReferences)	only #3166 claimed. The claim set has one member, so there is nothing to collide on.
added paths	disjoint. tests/session_truncation.py, tests/test_session_truncation_is_reported.py against scripts/report_truncated_test_run.py, tests/test_truncated_test_run_is_reported.py.
changelog slug	3167-session-truncation-is-reported against 3164-a-red-check-says-how-much-it-never-reached. Two names for one subject - the #2820/#2822 shape.
weak key (2 shared words AND a shared edited pre-existing test)	the conjunction is false: #3167 edits tests/conftest.py and docs/contributing.md, #3166 edits .github/workflows/test-lint.yml. No pre-existing test in common.

The claim key's silence is the structural one, and it is not an accident of this pair: step 1 itself prescribes Refs #N as the correct spelling for a deliberate second implementation, so the documented spelling for an intended duplicate is exactly the spelling that hides an unintended one.

They compose - main is not broken

Verified rather than assumed, because the two now sit in one pipeline: #3167 prints the subtraction into the log and #3166 parses that same log.

Reconstructed a truncated session log carrying #3167's section above the counts line and ran #3166's script over it: truncated, 34547 of 46583 items executed, 12036 never ran (25.8%), exit 0, annotation emitted. #3167's heading (session truncated: 34547 of 46583 collected tests ran) matches neither pattern it could have collided with - _COLLECTED requires collected N items and the heading says collected tests, and _SUMMARY_LINE requires a trailing in <n>s. #3166's _EXECUTED_LABELS also correctly counts xfailed/xpassed/error and excludes deselected/warnings/rerun, so a complete run with xfails is not misreported as truncated.

What is actually duplicated

Not the surface - the arithmetic. The subtraction now has two owners:

• test(ci): a session that stops early states how much of the suite never ran #3167 computes it in process: collected is len(session.items) (post-deselection), started is counted at pytest_runtest_logfinish.
• ci(test-lint): a red required check says how much of the suite it never reached #3166 re-derives it from text: the first collected N items line, minus the sum of the executed labels on the summary line.

They agree on the run above. The surface where they can diverge: #3166 falls back to collected when pytest prints / N deselected without a following / M selected token, while the plugin always uses the post-deselection count - so a deselecting run would state two different "never ran" numbers on two surfaces, with nothing to say which is right. Not observed on this suite; recorded as the drift surface, not as a defect.

Bounded remedy if it is wanted, and it is this repository's own convention ("give the vocabulary one owner and delegate to it, rather than a second inline copy that reports differently"): have the script prefer the line the plugin already states and keep the arithmetic as the fallback. Small, and optional.

Negative result: do not add the obvious intake key

Recorded so a later cycle does not rebuild it. The tempting fix is to widen the claim key to cross-references: an issue with two or more pull requests open at the same time referencing it, where at most one claims the close. Measured over 27 issues in #2709-#3164 against the 80 most recently updated closed/merged pull requests (#3077-#3168):

• selects about 27 pairs across 9 issues;
• 2 are genuine duplicate implementations - ci(test-lint): a red required check says how much of the suite it never reached #3166/test(ci): a session that stops early states how much of the suite never ran #3167 and fix(drivers/booster): construct the T1 DDS endpoints under the shared lock #3067/fix(drivers): open the Booster T1's channels under the shared DDS lock #3068 - so pair precision is about 7%, issue-level 2/9;
• fires on 9 of 27 issues, 33%.

That is the threshold this repository already names: a finding on a third of the queue is boilerplate, and a gate authors click through teaches them to click through it. The 25 false selections are epics (#2977, #2940), cross-cutting tripwire issues (#2963), the 476-file draft (#2848), and one recurring shape worth naming - the pull request that exposed the bug (#3161 references #3164; #2708 references #2709), which is never a duplicate of the fix.

It is also strictly disjoint from the existing key rather than a superset: the claim key catches #3132 (#3135 + #3136) and #3094 (#3095 + #3097), and "at most one claims" excludes both by construction.

Narrowed - at most 3 referencing pull requests, excluding pull requests that reference 3 or more issues, excluding pull requests already named in the issue body - it selects about 4 pairs, 2 genuine (about 50%), and still recovers #3164 and #3069. That version is defensible as an advisory line in a health sweep, not as a check. Even then it cannot reach the more common shape in this window: 2 of the 5 genuine pairs were sequential (#3066/#3086 on #2935, #2981/#3077 on #2963), and no simultaneity key sees those at all.

Suggested disposition

No revert: both changes are correct and their surfaces are complementary (one is available to every local pytest run, the other reaches a reviewer without downloading a 6.4 MB log). The actionable residue is the one-owner cleanup above. The intake-key half should stay closed with the numbers attached, which is the point of filing this rather than leaving it in a merge comment.

Refs #3164, #3166, #3167.

[cagataycali]

Took the one-owner residue and measured the drift surface. It is real, but the mechanism is not the one above, and the direction is the opposite of the one the issue expects.

The hypothesised shape is unreachable

The issue names it as "#3166 falls back to collected when pytest prints / N deselected without a following / M selected token". pytest does not print that. TerminalReporter.report_collect appends the token whenever the item count and the selected count differ:

if deselected:
    line += f" / {deselected} deselected"
if skipped:
    line += f" / {skipped} skipped"
if self._numcollected > selected:
    line += f" / {selected} selected"

deselected > 0 implies _numcollected > selected, so the two always arrive together. Confirmed by running it: a scoped run of tests/policies prints collected 5522 items / 5377 deselected / 145 selected, and the script reads 145 correctly.

What actually diverges: an intervening token

The tokens are appended in a fixed order, and the pattern expects deselected and selected adjacent:

collected N items[ / E errors][ / D deselected][ / S skipped][ / X selected]

An error or a skipped between them makes the selected group read as absent, and the count falls back to the pre-deselection total. collected 46403 items / 19 errors is what a full collection of this tree prints on a box missing some optional dependencies, so the shape is ordinary rather than contrived.

And the divergence is bigger than one number, because the other half of the subtraction is also measured on the wrong population: _EXECUTED_LABELS counts error and skipped, and a module that fails to import or skips itself produces those labels at collection without ever having been a selected item. The two errors point opposite ways and partly cancel.

The two owners disagree, on a run that completed

Measured on one real session rather than a reconstruction. -k selecting 2 of 5 items, alongside a module that skips itself; both selected items ran; exit code 0.

• len(session.items) = 2, entered = 2. The reporter is correctly silent.
• The script: truncated: 3 of 5 items executed, 2 never ran (40.0% of the suite). The failure count is a lower bound, not a total.

So the false direction is a completed run warned about, not a truncated one under-reported — which is the "a gate authors click through" threshold this issue names, arriving on green pull requests.

Across five sessions, one per arrangement of those tokens, four of the five misreported the extent. The fifth is the arrangement test_deselected_items_are_not_reported_as_never_run already poses, which is why it passed.

Disposition

#3170 takes both numbers off the collection line, which already carries the deselected count and the collection-phase outcomes, and delegates to the reporter's stated pair when its section is in the log — the bounded remedy above, with the second half needed because the reporter is silent on exactly the completed runs where the false warning appeared. All five arrangements then agree with pytest's own item counts.

The intake-key half is untouched; the numbers above are agreed and it should stay closed.

[cagataycali]

This issue's own residue produced a second instance of the shape it describes, within an hour of being filed, and the existing weak key caught it. Recording it because it is a measurement this issue asks for rather than a story: the negative result above says do not widen the claim key, and this is the datapoint that says the key already in place is the one doing the work.

The pair

pull request	opened	claim	fixes
#3170	05:46:33Z	Refs #3169	the token-order read and the executed-label numerator
#3171	05:55Z	Closes #3169	the token-order read only

Same two files, 9 minutes apart, same author. #3171 is closed as redundant and names #3170 as its supersedor.

Which key fired, and where

Not the claim key -- and this is the third consecutive pair for which that is true. #3170 spells Refs, #3171 spelled Closes, so the claim set had exactly one member and nothing to collide on. That is the structural silence this issue identifies, reproduced.

What fired was the weak key: two shared description words (is, selected) and a shared edited pre-existing test (tests/test_truncated_test_run_is_reported.py). It fired at the --all-open sweep of PR Workflow step 1, immediately after the second pull request opened, and before either had drawn a review -- so the pair cost zero approvals, against the ~35-minute windows and already-approved abandonments measured in that step.

The conjunction is what made it work, and both halves were load-bearing here: the two fragment slugs are 3169-selected-count-is-read-as-a-tally-set and 3170-truncation-extent-is-measured-on-selected-items, which is the #2820/#2822 shape again -- two names for one subject, so the slug key was silent. The shared edited test is what supplied the second half.

So this pair is a true positive for the 64.3%-precise key at its measured firing rate, and a miss for all three of the others. It does not move the numbers above; it is one observation, and it is consistent with them.

What it says about the negative result

Nothing that contradicts it. The narrowed cross-reference variant this issue costed would also have selected this pair (2 referencing pull requests, neither naming the other in the issue body), but it was not needed: the key that already exists reached it first and at the right moment. That strengthens the suggested disposition -- keep the intake-key half closed -- rather than reopening it.

One thing this pair does add, because it is not in the window measured above: both halves here were simultaneous and claim-disjoint, which is the combination the census found hardest. The sequential pairs (#3066/#3086, #2981/#3077) remain unreachable by any simultaneity key, and nothing here changes that.

Disposition of the residue

#3170 takes it, and takes more than this issue asked for. The bounded remedy suggested above -- have the script prefer the line the plugin already states, keeping the arithmetic as the fallback -- is implemented there, and it also fixes a second term this issue did not identify: executed summed the summary line's outcome labels, which include the ones collection produced (a module that fails to import is an error, one that skips itself for an absent optional dependency is a skipped), and neither was ever a selected item.

That matters for how the drift surface here is worded. This issue records the divergence as the script falling back to collected "when pytest prints / N deselected without a following / M selected token". Measured on pytest 9.1.1, that spelling is unreachable: report_collect writes selected whenever anything was deselected (if self._numcollected > selected). The fallback is reached by a token order mismatch instead -- error and skipped are appended between deselected and selected -- which is why the pair agreed on the suite as the required check invokes it and disagreed on a documented one (pytest -m 'not slow', with any of the several hundred module-level importorskip guards firing). Same surface, different mechanism, and the corrected mechanism is what #3170 grades against pytest's own session counts.

The two errors also point opposite ways and partly cancel, so "prefer the plugin's line" was the right instinct for a reason not stated above: it removes both terms at once instead of correcting one and leaving the other to be found later.

Left open deliberately. #3170 carries Refs, not Closes, so nothing currently claims this issue's close -- which is this issue's own finding applied to itself. Either #3170 takes the close, or this stays open for the intake-key numbers, which is what the suggested disposition above wants anyway.

[cagataycali]

The one-owner residue is taken in #3172. One correction to how this issue sizes the drift surface, measured rather than reasoned.

This issue records it as "a deselecting run would state two different never ran numbers on two surfaces, with nothing to say which is right ... recorded as the drift surface, not as a defect", and locates it in the / N deselected without / M selected case. Both halves are understated.

It is reachable with the selected token present. pytest's report_collect emits errors, deselected, skipped, selected in that order and only when each is nonzero, so the script's alternation -- which requires selected to follow deselected immediately -- loses the token to anything in between. Measured on pytest 9.0.3:

collected 10 items / 4 deselected / 1 skipped / 6 selected

And the outcome is a false verdict, not two numbers. That run reached all 6 items it selected. The script reported truncated: 7 of 10 items executed, 3 never ran (30.0% of the suite), plus the ::warning annotation -- on a green run. Over the seven shapes pytest can print, 1 was read correctly. The / 1 skipped case with no deselection is a second shape: right verdict, 11 of 10 items executed, and that 11 is what the share of the suite is computed from.

So the plugin was right on every one of them and the script was wrong on six, which makes "prefer the line the plugin already states" the fix rather than a tidy-up -- and it is why #3172 also brings the fallback onto pytest's own two rules (selected = collected - deselected; outcomes the collection line already accounted for are not items), since the fallback still has to answer for a log carrying no section.

Nothing here touches the intake-key half, which stays closed with your numbers.

[cagataycali]

New datapoint, and the first one where the pair was caught before the second merge rather than after: #3192 drew two independent PRs, #3194 (opened 07:39Z) and #3195 (merged 08:27Z as f4cf60c0). #3194 is now closed as superseded.

What the pair says about the detection keys this issue is about:

• Title similarity would not have fired. "docs(readme): remove archived Robots Sim link from header nav" against "docs(readme): the header nav does not offer an archived repository" - same change, no shared noun phrase beyond "nav" and "archived".
• The changelog fragment filename would not have fired either, and that is the interesting part: 3192-readme-drops-archived-robots-sim-link.md against 3192-readme-nav-drops-the-archived-sibling.md. Different names, same leading issue number.

That last line is a key the tree already has and nothing reads: two open PRs carrying a changelog.d/<same-number>-*.md fragment are by construction two implementations of one issue. It needs no similarity heuristic and no new metadata - the number is already mandatory in the filename by the fragment convention, and #3166/#3167 in the original report are the same shape (both fragments led with 3164).

It is also cheaper than the closing-reference key: Closes #3192 lives in prose a PR can omit or word differently, while the fragment number is gate-enforced (test_changelog_fragment_gate), so the signal is present on every compliant PR.

Cost of the miss here was small - one duplicate fragment, avoided by closing #3194 - but only because the second PR happened to land 48 minutes after the first was opened and a human-scale review window caught it. The #3164 pair shows what it costs when both merge.

One caveat before this becomes a rule: a legitimately split deliverable can ship two fragments for one issue in separate PRs (a large change decomposed per #2977's advice). So the check wants to be a warning that names the other PR, not a refusal - the duplicate is a claim about two whole implementations, which a reviewer can confirm in one look once the pair is named.

[cagataycali]

A third instance, with the timestamps that show why a repository-state key cannot catch this class

#3277 (fix(simulation/isaac): the parallel environment count is a count at both owners) was implemented twice, concurrently. The second implementation was abandoned unpushed, so this cost no review round — but it is worth recording, because the timings rule out the duplicate keys that have been proposed so far.

Timeline, all UTC, all from git/API metadata:

time	event
01:32:23	implementation A authored (f6d20da0, authoredDate)
01:57:25	implementation B branches from upstream/main @ e2cb5286
02:01:13	A's PR #3277 opens — the branch becomes visible on the fork
02:01:54	B's first commit (41 s later)
02:44:51	#3277 merges
02:49	B's pre-push git fetch fork refuses the push; B is abandoned

Both implementations were already written before either could observe the other. A git ls-remote / open-PR check at lead-selection time (01:57) would have returned nothing: A's branch did not exist on the fork until 02:01:13. This is the part I think the issue's framing is missing — the duplicate key is not merely weak, it is unavailable, because concurrent work is invisible until somebody's first push.

The convergence was not coincidental, and it is measurable

The two implementations independently chose:

• the same branch name — fix/isaac-env-count-domain (this is what actually blocked the push, since both push to the same fork);
• the same changelog fragment path — changelog.d/3277-isaac-env-count-domain.md, byte-identical, both having predicted the same next PR number;
• the same remedy: move both owners onto positive_count_error, replace num_envs or self._config.num_envs with an is None membership test, and refuse before _replicated latches.

That last one is the tell. Two independent passes over this tree converge because the lead is over-determined: the repo now has a well-established pattern (#3266, #3269, #3270, #3271, #3275) of "one quantity, two owners, only one graded", and replicate's num_envs was the most conspicuous remaining instance of it. Anything selecting work by that pattern lands on the same file.

Consequence for the fragment convention specifically

changelog.d/README.md justifies fragments by saying "no two PRs touch the same path, so there is nothing to reconcile". Naming a fragment after a predicted PR number reintroduces exactly the conflict class the convention removes, and it does so precisely in the duplicate-work case where a conflict would have been the useful signal. Had both PRs opened, they would have conflicted on that fragment and on nothing else. A slug-only fragment name (changelog.d/isaac-env-count-domain.md) would keep the no-conflict property for independent work and still collide for duplicated work — which is the behaviour you want from a duplicate key.

What I think this implies for the key

A cheap key that would have fired here, at lead-selection time, is the lead rather than the change: publishing the intended target (module + the quantity being fixed) before implementing, so a second pass sees a claim rather than an absence. The 4-minute window here means claim-at-selection is the only point where the two runs were distinguishable; every check after 02:01 catches it only once both implementations exist.

No action requested on the merged PR — #3277 is the better of the two implementations (it also caught a harm the abandoned one missed: the init log formats this field with %d, so a stored 2.7 was announced as num_envs=2 and a stored nan made that logging call raise). Recording the measurement here because this issue asks for the duplicate key, and these are the first timestamps I have seen that bound what a key can possibly observe.

[cagataycali]

One more pair for the table, caught before the second merged this time.

#3360 (opened 09:49:36Z) and #3361 (opened ~10:05Z, closed at 10:12Z as superseded) both fix the overwrite truthiness read in strands_robots/tools/lerobot_calibrate.py on the same two surfaces - the destructive row of #3356. Same author account, two scheduled runs, 16 minutes apart: inside the ~35-minute window every pair here has shared.

What each key read, all run from the second branch:

check	when	outcome	why it passed the pair
check_duplicate_claim.py --issue 3356	intake, and again before the first push	unique-claim	neither branch closes #3356 - both say Towards/Refs, deliberately, because the issue stays open for six more tools
check_duplicate_claim.py --all-open	after opening	unique-additions	fragment slugs differ (calibration-restore-overwrite-flag-domain vs lerobot-calibrate-overwrite-flag-domain), test filenames differ, and neither edits a pre-existing test - so the shared-words-AND-shared-test conjunction has no test half to fire on
check_merge_base_overlap.py --all-open	after opening	1 pair: #3360 + #3361 on lerobot_calibrate.py	the only key that reads the source path, which is the one thing two fixes of one defect cannot avoid sharing

So the pattern the issue title states held again: every duplicate key missed it. The overlap sweep is not a duplicate key - it fires on 127 of 2002 co-open pairs as a merge-order signal - but on a fresh pull request it is the check with recall here, and it costs one read.

What the second run could have asked at intake and did not: "which open pull requests already edit the file I am about to edit". That is a pullRequests(states: OPEN) { files } read against a path known before any commit exists, which is earlier than either --all-open mode can run. It would have read #3360 at minute 0 of #3361's authoring.

Cost this time: one review approval was not spent (#3361 was closed before anyone reviewed it), so the cost was the authoring run only.

[cagataycali]

A fifth pair, and the first one in this table that spent an external approval before it was caught.

#3368 and #3370 both fix the run_policy.fast_mode row of #3356 - the same three files (simulation/base.py, mujoco/simulation.py, tools/run_policy.py), the same helper shape (SimEngine._validate_posture_flag[s] binding boolean_flag_error), the same base commit (8377ddc). Same author account, two scheduled runs.

time (UTC)	event
16:46:55	#3368 opens, Closes #3356
16:57:57	#3368 approved
17:18:08	#3370 opens, Refs #3356 - 31 min after #3368, 20 min after its approval
17:25:23	#3370 approved (auto-merge already armed)
17:47:55	#3368 merges
18:09:13	#3370 closed as superseded; it was CONFLICTING on 2 files by then, which is the only reason auto-merge had not fired

Had #3370's required check finished before #3368 merged, both would have landed - the #3166/#3167 outcome, with two owners of one refusal in base.py.

What each key read

key	outcome	why
claim (closingIssuesReferences)	silent	Closes vs Refs - the structural hole, fourth consecutive pair
fragment leading number (proposed 09-04)	silent	changelog.d/3356-rollout-facades-... vs changelog.d/3370-rollout-posture-flags-.... One fragment led with the issue number, the other with its own PR number. The convention permits both, so the key depends on a spelling choice the same way the claim key does.
weak key (2 words AND shared edited pre-existing test)	silent	both add new test files, neither edits a pre-existing one
check_merge_base_overlap.py --all-open	would fire	three shared source paths
"which open PRs already edit the file I am about to edit" (proposed 09-09)	would fire at minute 0	#3368 was open and visible for 31 minutes before #3370's first commit - unlike the #3277 case, this pair was observable

#3368's description reports check_duplicate_claim.py --issue 3356: unique-claim and --all-open: unique-additions, both true and both useless here. #3370's description reports the full gate (ruff, mypy, 51844 tests) and no duplicate or overlap read at all. So the second run had 31 minutes of observable signal on the one key with recall and did not read it.

Two things this pair adds

1. The fragment-number key has the same weakness as the claim key. It only fires when both authors spell the fragment with the issue number. A Refs-style second implementation that names its fragment after its own PR number - which is what a run predicting its PR number does - defeats it exactly as Refs defeats the claim key. If the fragment convention is to double as a duplicate key, the leading number has to be the issue number, not the PR number, and that is a convention change rather than a check.

2. The cost has escalated. The four earlier pairs cost zero or one authoring run. This one cost a review approval from an account whose approvals are the binding constraint on this queue (process: a base-absorption merge costs a full external review round on the default ruleset, and #2907 has spent 8 of them - the resulting BLOCKED state is indistinguishable from reviewer latency #3197, feat(dashboard): mesh_bridge slice of #2848 — the signed rail honours the kill switch and an e-stop reports what the peers said (#2977) #3205), spent on a diff main already had. That is the cost the issue body predicted ("what a duplicate spends is a review approval") and it has now happened once.

Residue from #3370 that main lacks - a PolicyRunner.run raise that #3368 scoped out with a stated reason, and a docs paragraph in docs/simulation/overview.md - is named on the closed PR for a deliberate single follow-up, not carried here.

[cagataycali]

A sixth pair for the table - the first caught before a pull request existed, so it spent nothing.

Two scheduled runs both took #3359 (the Newton/Isaac in-flight reporting defect) inside the usual window. Same author account, same six source paths, same seam shape (a tri-state SimEngine read mirroring _request_policy_stop, overridden on all three backends, both mesh readers rerouted, docs/mesh.md "Which robot is running" rewritten, the fleet-stop population left alone).

time (UTC)	event
~20:10	run B intake: check_duplicate_claim.py --issue 3359 -> unique-claim (2 compared); check_merge_base_overlap.py --paths <4 files> -> only #3343, a different change to the same files
20:27:09	#3375 opens (run A), Closes #3359
20:36:52	#3375 approved by a second account
~21:05	run B pushes its branch to the fork, then re-reads both gates before createPullRequest
~21:05	--issue 3359 -> claimed by #3375; --paths -> #3375 on all six paths
~21:06	run B deletes its fork branch; no pull request opened

What each key read at the pre-PR re-read:

key	outcome
claim (closingIssuesReferences)	fired - both would have spelled Closes, the first pair here where the structural hole did not open
path overlap (--paths, the 09-09 proposal)	fired, six of six paths
fragment leading number	silent - #3375's fragment is 3375-rollouts-in-flight-on-every-backend.md (its own PR number), run B's was 3359-sim-peer-reports-the-rollout-in-flight.md (the issue number). The weakness your second bullet above names, observed a second time.

Two observations. The intake read was correct and useless at once: at minute 0 the rival did not exist, and it opened 17 minutes into a ~55-minute authoring window - so the re-read before the first pull request (PR Workflow step 5's "ask the intake question again before the first push") is the read with recall on this class, not the intake one. Cost avoided: the external approval already spent on #3375 would have had a competitor within the hour, which is the #3368/#3370 shape.

And the rival was authored by the same account from a different scheduled run, as every pair here has been. A per-account "is another run of me already on this issue" read is the same --paths question, so no new key is needed - only that the re-read happen at the pre-PR boundary rather than at intake alone.

#3375 is APPROVED, auto-merge armed, call-test-lint in progress; nothing owed.

[cagataycali]

Process record, no tree action. The lesson (two scheduled runs take one finding inside one window; check open branches on the fork for the same source paths before starting) belongs in the harness doctrine, not in an open issue.