When a post or comment contains a @mention of a username that does not exist, the system takes a long time to process or submit the content. The reporter observed a noticeable delay and speculated it was due to tagging a non-existent user.
Steps to Reproduce
Create a post or comment containing a @mention of a username that does not exist.
Submit the content.
Observe a noticeable delay before the submission completes.
Expected Behaviour
The system should handle non-existent usernames efficiently, either by: (a) validating the username exists before allowing the mention, (b) silently ignoring non-existent mentions, or (c) processing them as plain text without lookup.
Actual Behaviour
The system takes a long time to process or submit content containing a @mention of a non-existent username, likely due to attempting to look up or notify the non-existent user and hanging on the failure.
Environment
Not provided.
Reported by retoor via DevPlace.
## Summary
When a post or comment contains a @mention of a username that does not exist, the system takes a long time to process or submit the content. The reporter observed a noticeable delay and speculated it was due to tagging a non-existent user.
## Steps to Reproduce
1. Create a post or comment containing a @mention of a username that does not exist.
2. Submit the content.
3. Observe a noticeable delay before the submission completes.
## Expected Behaviour
The system should handle non-existent usernames efficiently, either by: (a) validating the username exists before allowing the mention, (b) silently ignoring non-existent mentions, or (c) processing them as plain text without lookup.
## Actual Behaviour
The system takes a long time to process or submit content containing a @mention of a non-existent username, likely due to attempting to look up or notify the non-existent user and hanging on the failure.
## Environment
Not provided.
---
*Reported by **retoor** via DevPlace.*
First I will bring up an isolated workspace with a fresh checkout and investigate whether the ticket matches the current state of the code before planning any change. I will announce every step here before I take it.
I am picking this ticket up now.
First I will bring up an isolated workspace with a fresh checkout and investigate whether the ticket matches the current state of the code before planning any change. I will announce every step here before I take it.
I am now reading the relevant source, tests, and prior work in the live checkout to verify the ticket and gather the context needed for a concrete plan. This can take a while; I will post periodic progress updates until it completes.
Starting research round 1 of at most 5.
I am now reading the relevant source, tests, and prior work in the live checkout to verify the ticket and gather the context needed for a concrete plan. This can take a while; I will post periodic progress updates until it completes.
Research compared the ticket requirements against the current source code and test suite, including autocomplete and IN clause behavior for non-existent @mentions. All three requested behaviors (validation, silent ignore, plain-text processing) are already implemented and covered by existing tests. The ticket therefore does not describe a real issue requiring code changes.
This mismatch likely stems from the ticket being based on an earlier or incomplete view of the system. The next step is to confirm whether this assessment is correct. Could you confirm whether this is still accurate, or should the ticket be closed?
Research compared the ticket requirements against the current source code and test suite, including autocomplete and `IN` clause behavior for non-existent @mentions. All three requested behaviors (validation, silent ignore, plain-text processing) are already implemented and covered by existing tests. The ticket therefore does not describe a real issue requiring code changes.
This mismatch likely stems from the ticket being based on an earlier or incomplete view of the system. The next step is to confirm whether this assessment is correct. Could you confirm whether this is still accurate, or should the ticket be closed?
First I will bring up an isolated workspace with a fresh checkout and investigate whether the ticket matches the current state of the code before planning any change. I will announce every step here before I take it.
I am picking this ticket up now.
First I will bring up an isolated workspace with a fresh checkout and investigate whether the ticket matches the current state of the code before planning any change. I will announce every step here before I take it.
What I tried: Retried this step 3 times.
What I found: Each attempt failed for internal reasons unrelated to this ticket. The details are in the operator's logs; this is not a judgment about the ticket.
The system needs operator attention before I can continue. Reply here once things are healthy and I will resume from where I left off.
I need input to continue.
What I tried: Retried this step 3 times.
What I found: Each attempt failed for internal reasons unrelated to this ticket. The details are in the operator's logs; this is not a judgment about the ticket.
The system needs operator attention before I can continue. Reply here once things are healthy and I will resume from where I left off.
First I will bring up an isolated workspace with a fresh checkout and investigate whether the ticket matches the current state of the code before planning any change. I will announce every step here before I take it.
I am picking this ticket up now.
First I will bring up an isolated workspace with a fresh checkout and investigate whether the ticket matches the current state of the code before planning any change. I will announce every step here before I take it.
I investigated the reported issue against the current source code and tests. The codebase already handles non-existent username mentions exactly as requested: the IN clause silently excludes unknown usernames, server-side rendering performs no lookup, and client-side autocomplete prevents accidental mentions. A test confirms that @ghost_zzz produces no notification and no delay.
The ticket therefore appears to be a mismatch with the current implementation. Could you confirm whether this is still accurate, or should the ticket be closed?
I investigated the reported issue against the current source code and tests. The codebase already handles non-existent username mentions exactly as requested: the `IN` clause silently excludes unknown usernames, server-side rendering performs no lookup, and client-side autocomplete prevents accidental mentions. A test confirms that `@ghost_zzz` produces no notification and no delay.
The ticket therefore appears to be a mismatch with the current implementation. Could you confirm whether this is still accurate, or should the ticket be closed?
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Summary
When a post or comment contains a @mention of a username that does not exist, the system takes a long time to process or submit the content. The reporter observed a noticeable delay and speculated it was due to tagging a non-existent user.
Steps to Reproduce
Expected Behaviour
The system should handle non-existent usernames efficiently, either by: (a) validating the username exists before allowing the mention, (b) silently ignoring non-existent mentions, or (c) processing them as plain text without lookup.
Actual Behaviour
The system takes a long time to process or submit content containing a @mention of a non-existent username, likely due to attempting to look up or notify the non-existent user and hanging on the failure.
Environment
Not provided.
Reported by retoor via DevPlace.
I am picking this ticket up now.
First I will bring up an isolated workspace with a fresh checkout and investigate whether the ticket matches the current state of the code before planning any change. I will announce every step here before I take it.
Starting research round 1 of at most 5.
I am now reading the relevant source, tests, and prior work in the live checkout to verify the ticket and gather the context needed for a concrete plan. This can take a while; I will post periodic progress updates until it completes.
Research compared the ticket requirements against the current source code and test suite, including autocomplete and
INclause behavior for non-existent @mentions. All three requested behaviors (validation, silent ignore, plain-text processing) are already implemented and covered by existing tests. The ticket therefore does not describe a real issue requiring code changes.This mismatch likely stems from the ticket being based on an earlier or incomplete view of the system. The next step is to confirm whether this assessment is correct. Could you confirm whether this is still accurate, or should the ticket be closed?
I am picking this ticket up now.
First I will bring up an isolated workspace with a fresh checkout and investigate whether the ticket matches the current state of the code before planning any change. I will announce every step here before I take it.
I need input to continue.
What I tried: Retried this step 3 times.
What I found: Each attempt failed for internal reasons unrelated to this ticket. The details are in the operator's logs; this is not a judgment about the ticket.
The system needs operator attention before I can continue. Reply here once things are healthy and I will resume from where I left off.
I am picking this ticket up now.
First I will bring up an isolated workspace with a fresh checkout and investigate whether the ticket matches the current state of the code before planning any change. I will announce every step here before I take it.
I investigated the reported issue against the current source code and tests. The codebase already handles non-existent username mentions exactly as requested: the
INclause silently excludes unknown usernames, server-side rendering performs no lookup, and client-side autocomplete prevents accidental mentions. A test confirms that@ghost_zzzproduces no notification and no delay.The ticket therefore appears to be a mismatch with the current implementation. Could you confirm whether this is still accurate, or should the ticket be closed?