Inconsistencies / Needs Clarification

This page intentionally lists places where the codebase does not expose a fully formalized contract.

1. Not every result family has a formal schema

What is visible in code:

• many result families are normalized by dedicated normalizers
• some command results are still direct service dicts or TDLib-like {"@type":"ok"} payloads
• there is no single schema registry or schema package covering all command outputs

2. open_dialog is a stream, not a classic request/response pair

This is a feature of the current implementation, but it means command pages must describe multiple event types instead of one result shape.

3. download_file / get_custom_emoji_media are two-step flows

The immediate command result is only an acknowledgement. The actual media path arrives later through media_ready.

4. Cache backend details are outside dialogs

DialogCache depends on Django cache, but the concrete backend is configured elsewhere.

5. Search/public-user semantics need naming review

The command search_user currently delegates to BootstrapService.search_user(), which calls search_public_chat() under the hood. The name suggests user lookup, but the underlying TDLib call is public chat search by username.

6. Security / ACL checks at the gateway level are not evident here

TDLibListChatsConsumer accepts connections and routes actions, but object-level authorization rules are not enforced inside this consumer. They may exist elsewhere in the application stack, but that is not visible from the dialogs code alone.

7. Replay implementation is cache-backed

ReplayService explicitly states that it is a short-horizon cache-backed recovery path until dedicated TG event replay workers are introduced.

8. Documentation build tooling is not pinned in repo dependencies

mkdocs.yml is provided, but the repository does not currently pin MkDocs packages. Build/install steps require environment verification.