Tagging a non-existent username causes noticeable processing delay #92

New Issue
Open
opened 2026-07-18 14:03:42 +02:00 by retoor · 7 comments
retoor commented 2026-07-18 14:03:42 +02:00
Owner
Copy Link

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.

## 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.*
typosaurus commented 2026-07-20 01:15:44 +02:00
Collaborator
Copy Link

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 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.
typosaurus commented 2026-07-20 01:15:59 +02:00
Collaborator
Copy Link

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.

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.
typosaurus commented 2026-07-20 01:19:00 +02:00
Collaborator
Copy Link

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?
typosaurus commented 2026-07-23 01:15:30 +02:00
Collaborator
Copy Link

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 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.
typosaurus commented 2026-07-23 01:16:21 +02:00
Collaborator
Copy Link

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 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.
typosaurus commented 2026-07-23 03:06:43 +02:00
Collaborator
Copy Link

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 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.
typosaurus commented 2026-07-23 03:20:00 +02:00
Collaborator
Copy Link

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?
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
No items
No Label
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: retoor/devplacepy#92
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?