Problem

On freecode.academy, some URLs with percent-encoded special characters may return a 404, even though the corresponding page likely exists.

Example:

/comments/topics/dzheneriki-typescript/nu-vot-ts-tebe-govorit-%22ty-zanimaeshsya-figney%22,-i

Hypothesis: at one of the routing stages, slug lookup, or URL matching steps, URL decoding (decodeURIComponent or equivalent) is either missing or incorrectly performed, causing the slug to be compared in its encoded form against the stored decoded value, or vice versa.

What to Check

1. Trace the full path of the URL from the HTTP request to the entity lookup by slug:
   • framework/router;
   • route params;
   • server/API handler;
   • DB query;
   • canonical URL/link generation.
2. Check at which stage %22 and other percent-encoded characters are decoded automatically, and where explicit decoding is required.
3. Prevent double decoding (decodeURIComponent over an already decoded param), especially for %, %25, %2F, and other sensitive sequences.
4. Verify the slug format in the DB: whether it is stored decoded, encoded, or normalized.
5. Check the link generator: URLs must be encoded exactly once (encodeURIComponent/URL API where necessary).
6. Specifically test the following characters:
   • quotes " / %22;
   • commas;
   • spaces / %20;
   • Cyrillic characters;
   • %;
   • ?, #, / inside a potential slug.
7. Check old, already published URLs and backward compatibility. If different historical variants of the same slug exist, add a redirect/canonical normalization instead of a 404 where necessary.

Specific Case

For the URL:

/comments/topics/dzheneriki-typescript/nu-vot-ts-tebe-govorit-%22ty-zanimaeshsya-figney%22,-i

we need to find out:

• whether a record with the logically corresponding slug exists;
• what value the application actually receives as the route param;
• what value is used in the DB query;
• whether the 404 is fixed after proper normalization/decode.

Acceptance Criteria

• The exact cause of the 404 for the given URL has been found.
• URLs with special characters correctly open existing pages.
• There is no double decode and related errors/exceptions.
• Link generation and route param reading use a consistent slug format.
• Invalid URLs still return a proper 404 rather than causing an application error.
• Tests have been added for at least %22, Cyrillic characters, and %25/double encoding.
• Backward compatibility of existing links has been verified; a redirect to the canonical URL has been added if necessary.