Problem:
- After wizard form submission, need to wait for claim data from n8n
- Claim data comes via Redis channel claim:plan:{session_token}
- Need to display confirmation form with claim data
Solution:
1. Backend: Added SSE endpoint /api/v1/claim-plan/{session_token}
- Subscribes to Redis channel claim:plan:{session_token}
- Streams claim data from n8n to frontend
- Handles timeouts and errors gracefully
2. Frontend: Added subscription to claim:plan channel
- StepWizardPlan: After form submission, subscribes to SSE
- Waits for claim_plan_ready event
- Shows loading message while waiting
- On success: saves claimPlanData and shows confirmation step
3. New component: StepClaimConfirmation
- Displays claim confirmation form in iframe
- Receives claimPlanData from parent
- Generates HTML form (placeholder - should call n8n for real HTML)
- Handles confirmation/cancellation via postMessage
4. ClaimForm: Added conditional step for confirmation
- Shows StepClaimConfirmation when showClaimConfirmation=true
- Step appears after StepWizardPlan
- Only visible when claimPlanData is available
Flow:
1. User fills wizard form → submits
2. Form data sent to n8n via /api/v1/claims/wizard
3. Frontend subscribes to SSE /api/v1/claim-plan/{session_token}
4. n8n processes data → publishes to Redis claim:plan:{session_token}
5. Backend receives → streams to frontend via SSE
6. Frontend receives → shows StepClaimConfirmation
7. User confirms → proceeds to next step
Files:
- backend/app/api/events.py: Added stream_claim_plan endpoint
- frontend/src/components/form/StepWizardPlan.tsx: Added subscribeToClaimPlan
- frontend/src/components/form/StepClaimConfirmation.tsx: New component
- frontend/src/pages/ClaimForm.tsx: Added confirmation step to steps array
5.5 KiB
Лог сессии разработки - 20 ноября 2025
Проблема (из предыдущей сессии)
После верификации телефона не отображался список черновиков, хотя в базе данных есть заявки с unified_id.
Решение
1. Исправлен SQL запрос в backend (claims.py)
Проблема: Запрос строился через конкатенацию строк, что могло приводить к проблемам с параметрами.
Решение: Переписан SQL запрос - теперь используется прямой запрос для каждого случая:
- Для
unified_id: прямой запросWHERE c.unified_id = $1 - Для
phone: подзапрос черезclpr_user_accountsиclpr_users - Для
session_id: прямой запросWHERE c.session_token = $1
if unified_id:
query = """
SELECT
c.id,
c.payload->>'claim_id' as claim_id,
c.session_token,
c.status_code,
c.channel,
c.payload,
c.created_at,
c.updated_at
FROM clpr_claims c
WHERE c.unified_id = $1
ORDER BY c.updated_at DESC
LIMIT 20
"""
params = [unified_id]
2. Улучшена обработка черновиков в frontend (ClaimForm.tsx)
Проблема: Черновики из Telegram имеют другую структуру данных (данные в payload.body), а не напрямую в payload.
Решение: Добавлена поддержка обоих форматов:
- Telegram формат: данные в
payload.body.wizard_plan,payload.body.answers - Web form формат: данные напрямую в
payload.wizard_plan,payload.answers
// ✅ Для telegram черновиков данные могут быть в payload.body
const body = payload.body || {};
const isTelegramFormat = !!payload.body;
// ✅ Извлекаем данные из body (telegram) или напрямую из payload (web_form)
const wizardPlanRaw = body.wizard_plan || payload.wizard_plan;
const answersRaw = body.answers || payload.answers;
const problemDescription = body.problem_description || payload.problem_description || body.description || payload.description;
// ✅ Парсим wizard_plan и answers, если они строки (JSON)
let wizardPlan = wizardPlanRaw;
if (typeof wizardPlanRaw === 'string') {
try {
wizardPlan = JSON.parse(wizardPlanRaw);
} catch (e) {
console.warn('⚠️ Не удалось распарсить wizard_plan:', e);
}
}
3. Улучшена обработка claim_id
Проблема: claim_id может быть в разных местах в зависимости от формата данных.
Решение: Добавлен поиск claim_id в нескольких местах:
const finalClaimId = claim.claim_id || payload.claim_id || body.claim_id || claim.id || formData.claim_id || claimId;
4. Добавлено детальное логирование
- В
loadDraft: логирование всех этапов загрузки черновика - В
get_draft(backend): логирование найденных данных - В
list_drafts(backend): тестовые COUNT запросы для отладки
5. Исправлена обработка claim_id в backend
В get_draft теперь извлекается claim_id из payload, если его нет в row:
claim_id_from_payload = payload.get('claim_id') if isinstance(payload, dict) else None
final_claim_id = row.get('claim_id') or claim_id_from_payload
Результат
✅ Черновики теперь возвращаются! API корректно возвращает список черновиков для unified_id.
Файлы изменены
-
backend/app/api/claims.py:- Переписан SQL запрос для
list_drafts - Добавлено логирование и тестовые COUNT запросы
- Улучшена обработка
claim_idвget_draft
- Переписан SQL запрос для
-
frontend/src/pages/ClaimForm.tsx:- Добавлена поддержка формата Telegram черновиков
- Улучшена обработка
claim_idиз разных источников - Добавлено детальное логирование загрузки черновика
-
frontend/src/components/form/Step1Phone.tsx:- (Возможно, были изменения для передачи unified_id)
-
frontend/src/components/form/StepDraftSelection.tsx:- (Возможно, были изменения для отображения черновиков)
Текущий статус
✅ Работает: API возвращает черновики ✅ Работает: Загрузка черновиков поддерживает оба формата (Telegram и web_form) ⚠️ Требует проверки: Отображение черновиков в UI (StepDraftSelection)
Следующие шаги
- Проверить отображение черновиков в UI
- Протестировать загрузку черновика из Telegram формата
- Убедиться, что все данные корректно восстанавливаются в форму