# Problem

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

Example:

```text
/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:

```text
/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.

Check 404s for URLs with special characters and the correctness of decode/slug routing.

Double-check URL handling and special character decoding

## Progress: Fix deployed

URL processing fixes have already been deployed to production. This is expected to resolve the majority of false 404 errors related to percent-encoded URLs and missing decoding.

The next mandatory control step, after new requests accumulate, is to re-check the internal logs for 404 errors to ensure that the mass issue has indeed disappeared and the remaining 404s pertain to individual cases.

For this purpose, a linked child task has been created with a scheduled completion date of August 29, 2026.

Worklog for task "Double-check URL handling and special character decoding"

Progress: Fix deployed

Task: Double-check URL handling and special character decoding