(low) PilotRequestModal/deriveTrackingId: показанный лиду «Номер заявки GD-XXXXXXXX» не хранится в БД и не находится поддержкой #1447

New issue

Closed

opened 2026-06-15 05:55:45 +00:00 by bot-backend · 0 comments

bot-backend commented

2026-06-15 05:55:45 +00:00

Collaborator

Severity: low · Категория: report · Файл: frontend/src/components/landing/PilotRequestModal.tsx:49-54, 274-283

frontend/src/components/landing/PilotRequestModal.tsx:52-54, 203, 274-283. deriveTrackingId(id) формирует «GD-» + первые 8 hex-символов UUID в верхнем регистре (id.replace(/-/g,'').slice(0,8).toUpperCase()) и в success-state модалки показывает лиду «Номер заявки: GD-XXXXXXXX». Этот идентификатор существует только на фронте: бэкенд backend/app/api/v1/pilot.py (create_pilot_request) возвращает лишь {id: <полный uuid as text>, created_at, status:'received'} и логирует полный uuid (logger.info ... id=%s), а схема data/sql/118_pilot_requests.sql (строки 68-79) содержит колонки id uuid, name, phone, email, company, message, source, user_agent, created_at, notified_at — отдельного tracking/номера нет. Telegram-нотификация — TODO #307. Импакт: если лид перезвонит и назовёт «GD-7F3A8C2E», поддержка не сможет прямо найти заявку — придётся реверсить 8 hex в начало uuid (SELECT ... WHERE id::text ILIKE '7f3a8c2e%'), причём в UI верхний регистр vs lower-case uuid в БД, и совпадение по первым 8 hex не гарантированно уникально. Данные не теряются (полный uuid сохранён), но обещанный клиенту трекинг-номер практически неюзабелен. Как чинить: либо хранить/возвращать сам короткий номер (отдельная колонка/сгенерированный человекочитаемый код в таблице и в ответе бэка), либо в UI показывать полный data.id (или его lower-case префикс) и согласовать формат поиска с поддержкой; как минимум документировать SQL-запрос для поиска по префиксу с учётом регистра.

Почему баг: Текст «Заявка принята … Номер заявки: GD-…» обещает клиенту трекинг-идентификатор, по которому нигде нельзя поднять заявку: значение генерируется только на фронте (deriveTrackingId), не возвращается бэкендом как отдельное поле и не пишется в таблицу. Это рассинхрон между тем, что сказано клиенту в отчёте/модалке, и тем, что реально хранится — классический «врёт в клиентском сообщении» низкой тяжести: данные не теряются (полный uuid сохранён), но обещанный «номер заявки» практически неюзабелен для поддержки.

Как чинить: Либо (а) возвращать и сохранять стабильный человекочитаемый номер на бэкенде (например столбец public_ref с генерацией при INSERT) и отдавать его в ответе, либо (б) не называть это «Номер заявки» (трекинг-обещание), а показывать нейтральный текст без идентификатора, либо (в) хотя бы документировать в поддержке reverse-lookup (lower-case, LIKE по префиксу uuid) и убедиться в достаточной длине префикса.

_{deep-audit «армия ботов 2» · verify+harden, confidence 0.9 · unit U91}

**Severity:** low · **Категория:** report · **Файл:** `frontend/src/components/landing/PilotRequestModal.tsx:49-54, 274-283` frontend/src/components/landing/PilotRequestModal.tsx:52-54, 203, 274-283. deriveTrackingId(id) формирует «GD-» + первые 8 hex-символов UUID в верхнем регистре (id.replace(/-/g,'').slice(0,8).toUpperCase()) и в success-state модалки показывает лиду «Номер заявки: GD-XXXXXXXX». Этот идентификатор существует только на фронте: бэкенд backend/app/api/v1/pilot.py (create_pilot_request) возвращает лишь {id: <полный uuid as text>, created_at, status:'received'} и логирует полный uuid (logger.info ... id=%s), а схема data/sql/118_pilot_requests.sql (строки 68-79) содержит колонки id uuid, name, phone, email, company, message, source, user_agent, created_at, notified_at — отдельного tracking/номера нет. Telegram-нотификация — TODO #307. Импакт: если лид перезвонит и назовёт «GD-7F3A8C2E», поддержка не сможет прямо найти заявку — придётся реверсить 8 hex в начало uuid (SELECT ... WHERE id::text ILIKE '7f3a8c2e%'), причём в UI верхний регистр vs lower-case uuid в БД, и совпадение по первым 8 hex не гарантированно уникально. Данные не теряются (полный uuid сохранён), но обещанный клиенту трекинг-номер практически неюзабелен. Как чинить: либо хранить/возвращать сам короткий номер (отдельная колонка/сгенерированный человекочитаемый код в таблице и в ответе бэка), либо в UI показывать полный data.id (или его lower-case префикс) и согласовать формат поиска с поддержкой; как минимум документировать SQL-запрос для поиска по префиксу с учётом регистра. **Почему баг:** Текст «Заявка принята … Номер заявки: GD-…» обещает клиенту трекинг-идентификатор, по которому нигде нельзя поднять заявку: значение генерируется только на фронте (deriveTrackingId), не возвращается бэкендом как отдельное поле и не пишется в таблицу. Это рассинхрон между тем, что сказано клиенту в отчёте/модалке, и тем, что реально хранится — классический «врёт в клиентском сообщении» низкой тяжести: данные не теряются (полный uuid сохранён), но обещанный «номер заявки» практически неюзабелен для поддержки. **Как чинить:** Либо (а) возвращать и сохранять стабильный человекочитаемый номер на бэкенде (например столбец public_ref с генерацией при INSERT) и отдавать его в ответе, либо (б) не называть это «Номер заявки» (трекинг-обещание), а показывать нейтральный текст без идентификатора, либо (в) хотя бы документировать в поддержке reverse-lookup (lower-case, LIKE по префиксу uuid) и убедиться в достаточной длине префикса. --- <sub>deep-audit «армия ботов 2» · verify+harden, confidence 0.9 · unit U91</sub>