[MaxFreedomPollard]

Proposed Changes

When a comment mentions a user whose username contains - or ., the mention notification goes to the wrong account, or to nobody, although the link in the comment is right.

handleSendReply builds the request from two helpers (ui/src/components/Comment/index.tsx:228-235): parseUserInfo turns @name into the link stored in original_text, and matchedUsers produces mention_username_list, the usernames the backend notifies. They disagree on which characters a username may contain:

// matchedUsers, ui/src/utils/common.ts:98-99
const globalReg = /\B@([\w|]+)/g;
const reg = /\B@([\w\\_\\.]+)/;

// parseUserInfo, ui/src/utils/common.ts:119
const globalReg = /\B@([\w\\_\\.\\-]+)/g;

Hyphenated usernames are the common case: sign-up derives the username from the display name by lowercasing it and replacing spaces with - (internal/service/user_common/user.go:201-202), so "Jane Doe" becomes jane-doe, and the profile settings accept a-z, 0-9 and - . _. Picking jane-doe in the mention dropdown inserts @jane-doe (ui/src/components/Mentions/index.tsx:110), and the comment links to /users/jane-doe, but mention_username_list is ["jane"]. The backend looks each name up exactly (internal/service/comment/comment_service.go:262, notificationMention), so a user named jane, if there is one, gets a "mentioned you" notification for a comment that has nothing to do with them, and jane-doe gets nothing. Since a non-empty mention list also skips the usual notification to the post's author, with no jane nobody is notified at all.

Comments that go through review already get this right: internal/service/review/review_service.go:472 reads the usernames back from the stored links with converter.GetMentionUsernameList, which yields jane-doe. Only the direct path uses the list from the UI.

• Use the parseUserInfo pattern in matchedUsers, so the users who are notified are the users the comment links to, as in the review path
• | is no longer in the pattern: before, a comment containing @| made matchedUsers throw a TypeError (the inner pattern found no match), so it could not be submitted

A mention typed directly before a full stop (thanks @alice.) was already linked to /users/alice.; its notification now follows the link, as the review path already does. Trimming trailing punctuation would change the links too, and usernames may end in ., so that is left out of this fix.

Testing

The UI has no test runner, so this adds no unit test. I loaded ui/src/utils/common.ts from dev (a570e3a) and from this branch in Node 22 with type stripping (node --experimental-strip-types, with i18next, diff and the two @/common/* imports stubbed), and compared matchedUsers(text) with the usernames in the links parseUserInfo(text) produces:

comment	links to	notified before	notified after
@jane-doe can you take a look?	jane-doe	jane	jane-doe
cc @john.smith and @sam_lee	john.smith, sam_lee	john, sam_lee	john.smith, sam_lee
@alice thanks	alice	alice	alice
see @|	none	throws TypeError	none

Over 20,000 random strings of up to 24 characters drawn from letters, digits, - . _ @ | , ! ?, spaces and newlines, the two disagreed on 5,309 before (1,464 of them throwing) and on none after. tsc, ESLint and a run in the browser were not done here.

🤖 Generated with Claude Code