test(fqn): guard against Unicode project-name collisions - #2219

Thanks for opening this — it has been seen, and it is queued.

This note is automated, but it is not a brush-off: it exists so you know where your PR stands instead of having to guess from silence.

Current review status: working through a backlog. 0.9.1-rc.1 is out, so the release freeze that held reviews is over — but it left a large queue of open pull requests behind it, and we are reading through them oldest-first. The background is in discussion #1144.

What that means for this PR, concretely:

• It will not be closed for inactivity. No stale bot touches pull requests here.
• It may still sit a while before a human reads it. That is on us, not on you.
• Older PRs are read first, so a recent one is not being skipped — it is behind a queue.

Things that will genuinely speed it up whenever review does happen:

• Keep it rebased on main — the tree is moving quickly right now, and a conflicting branch cannot be reviewed as the diff you intended.
• Get CI green, or say which failures you believe are pre-existing.
• Keep the change to one claim. Bundled features and refactors get split before they get merged, which costs you a round trip.
• Every commit needs a sign-off (git commit -s) — CI enforces DCO.

If this fixes a bug, a reproduction we can run is worth more than a description of the symptom.

Thanks for contributing, and sorry in advance for the wait.

Thank you for adding the Unicode collision regression. Current FQN encoding already contains the underlying Unicode handling, so this is valuable protection of an existing fix rather than a newly delivered runtime correction. We should keep #571's requested reporter verification separate and not close it solely because this test lands.

Thank you — a guard against Unicode project-name collisions in FQNs is a sharp thing to think of, and 14 lines in one test file makes it easy to say yes to.

One blocker: the dco check.

Your commit carries no Signed-off-by trailer — the message is a headline with an empty body, so there is nothing for the check to parse. (Not the blank-line trap, where the sign-off sits outside the trailer block and git's parser skips it while grep still finds it; here there is no trailer at all.)

git commit --amend -s
git push --force-with-lease

Everything else is green (31 success, 1 skipped). Sign it off and I will merge it.

One question, genuinely curious rather than a review demand: does this guard fail today, or does it pin behaviour that is already correct? Both are worth having and I will take either — but they are different things, and if it is a pinning test I would like to say so in the merge so the next person reading it knows it was never a bug report.

#2241 and #2242 merged cleanly today with correct sign-offs — the habit is already there, these branches just predate it.

Thanks again for the Unicode collision guard. The description makes clear that this protects behavior already present, which answers the earlier question. The recorded sign-off request remains the next contributor step; reporter verification on #571 should stay separate from landing this test.

Thanks again for the Unicode collision guard. The description answers the behavior-versus-regression question; the remaining recorded contributor step is the commit sign-off. Please let us know when that is updated, keeping reporter verification on #571 separate.

Thank you, @lorenzozanee, for this guard. You picked the right property to pin: the existing #571 test checks one exact string, while yours checks that two different CJK folders can never collapse into the same project name, and that both names still pass the project-name validator. That is the failure users would actually hit, and it is now protected.

We landed it in #2950 (merge 0640103), with you credited as co-author on the commit. We took that route because this branch's commit has no DCO sign-off, which only you can add, and we did not want the test to wait any longer. The one addition is a check that each name keeps the hex image of its own folder, which is the "remains part of the project identity" point from your description.

Closing this one in favor of #2950. #571 stays open for the reporter's own verification, as discussed. Thanks again for the careful work.