The issue_labels_sync idempotency key varies by runner locale

[dwin-gharibi]

Summary

flushIssueLabelMutationBatch in src/clawsweeper-label-mutations.ts sorts the
batched additions and removals with String.prototype.localeCompare and joins them
into the mutation identity the action ledger dedupes on:

let additions = [...batch.additions.values()].sort((left, right) => left.localeCompare(right));
const removals = [...batch.removals.values()].sort((left, right) => left.localeCompare(right));
// ...
identity: `issue_labels_sync:${number}:add=${additions.join("|")}:remove=${removals.join("|")}`

localeCompare is locale-sensitive, so the identity depends on the ICU
configuration of the machine that produced it.

Impact

The identity is an idempotency key. Two spellings of the same key are two different
keys, so a label sync that has already been applied is not recognized as a repeat
and can be published again.

Observed against the shipped module, same label set and same batching:

en_US.UTF-8  issue_labels_sync:321:add=Alpha|apple|äpple|zulu:remove=
sv_SE.UTF-8  issue_labels_sync:321:add=Alpha|apple|zulu|äpple:remove=

There is a second, locale-independent failure in the same line. localeCompare
returns 0 for strings a collator treats as equivalent but that are not equal, so
it is not a total order. GitHub permits emoji in label names, and two names
differing only by a zero-width joiner tie:

"status: 👀‍ ready".localeCompare("status: 👀 ready")  // 0

Array.prototype.sort therefore leaves them in whatever order they were queued, and
the identity follows the queue rather than the label set — on a single runner, with
no locale involved.

Reproduction

Queue the same label set in two different orders and compare the published
identity, or run the same set under two LC_ALL values. Both are covered by
docs/proof/label-sync-identity-determinism/run-proof.mjs.

Proposed solution

Sort with compareCodeUnits from src/stable-json.ts:

import { compareCodeUnits } from "./stable-json.js";
// ...
let additions = [...batch.additions.values()].sort(compareCodeUnits);
const removals = [...batch.removals.values()].sort(compareCodeUnits);

Code-unit order is a total order and is fully specified, so the key depends only on
the label set. It is also the ordering the action ledger already uses for its
canonical JSON, which keeps the two consistent.

Expected fallout

Code-unit order puts uppercase before lowercase, so P2 sorts before
impact:message-loss. That changes the order of names inside the --add-label and
--remove-label arguments. GitHub treats those as sets, so the resulting label
state is unchanged, but three assertions in test/label-mutation-batch.test.ts
pin the current order and need updating:

• an exact-publication label batch emits one combined deterministic issue edit
• label definition discovery is cached across item batches
• optional batch failures retain successful final operations and report skipped additions

In the third, the per-label retry order also flips, which moves where the receipt
lands. result.skippedAdditions is unaffected.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed August 15, 2026, 12:56 PM ET / 16:56 UTC.

Summary
Keep open: current main still uses locale-sensitive ordering to construct the label-sync idempotency identity, and the focused fix remains open at #1139. Likely related people: Peter Steinberger (high confidence).

Reproducibility: yes. —source reproducible: current main builds the deduplication identity from localeCompare-sorted labels, while the repository’s own comparator documentation establishes why that ordering can vary or tie for distinct strings.

Next step
#1139 already owns the narrow repair, so dispatching another fix PR would duplicate contributor work.

Review details

Best possible solution:

Land the focused, proof-backed repair in #1139 after its current review is complete, preserving the existing batch and ledger behavior while making only identity ordering deterministic.

Do we have a high-confidence way to reproduce the issue?

Yes—source reproducible: current main builds the deduplication identity from localeCompare-sorted labels, while the repository’s own comparator documentation establishes why that ordering can vary or tie for distinct strings.

Is this the best way to solve the issue?

Yes—the linked PR’s reuse of the existing code-unit comparator is the narrowest maintainable repair; a second repair branch would duplicate the active implementation work.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against d389e6addf4d.

Label changes

Label justifications:

• P2: The report establishes a bounded automation idempotency defect that can cause duplicate label publication.
• impact:other: The affected action-ledger publication behavior is meaningful operational impact outside the more specific owned classes.

Evidence reviewed

What I checked:

• Current main still has the defect: The additions and removals are sorted with default-locale localeCompare, and those joined arrays become the issue_labels_sync identity passed to the observed mutation command. (src/clawsweeper-label-mutations.ts:238, d389e6addf4d)
• Repository comparator documents the required invariant: The existing canonical comparator is explicitly a UTF-16 code-unit total order and documents both locale dependence and ties from localeCompare. (src/stable-json.ts:4, 765644804756)
• Focused implementation candidate is open: The supplied GitHub context shows fix(labels): make the label sync identity locale independent #1139 explicitly closing this issue, is cleanly mergeable, and supplies real-behavior proof for the same ordering defect. (f6071b714100)
• Feature-history provenance: The current batch implementation and its focused tests were introduced together by the feature commit, making its author the clearest routing contact. (src/clawsweeper-label-mutations.ts:238, 765644804756)

Likely related people:

• Peter Steinberger: Git history shows the current label-mutation implementation and its dedicated test file were introduced in one feature commit. (role: introduced current batching behavior; confidence: high; commits: 765644804756; files: src/clawsweeper-label-mutations.ts, test/label-mutation-batch.test.ts, src/stable-json.ts)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.