WhatsApp Group Monitoring — jak to działa

Zaktualizowano 2026-10-08 (#7576). Źródłem wiadomości NIE jest już WAHA (zdekomisjonowane 2026-07-02). Od tego czasu wiadomości zbiera usługa wa-web-collector (Baileys, kontener Docker na bms-4). Webhook n8n wa-router (dawny odbiornik WAHA) jest nieaktywny i nie bierze udziału w przepływie. Kanoniczny opis samego kolektora: whatsup-android-chat-puller-operations.md oraz playbook odzyskiwania playbooks/wa-web-collector-recovery.md.

Architektura przepływu wiadomości

WhatsApp Web  →  wa-web-collector (Baileys, Docker `wa-web-collector` na bms-4)
                    ↓ upsert (SUPABASE_URL + klucz serwisowy)
              Supabase: whatsapp_messages (status = 'new')
                    ↓ co 5 min (n8n: wa-ai-to-inbox, Schedule Trigger)
              claim_wa_messages (RPC)  →  Claude AI (przez SSH)  →  parsowanie zgłoszeń
                    ↓
              process_wa_group_tickets (RPC)  →  status = 'na_zgloszeniu_email'
                    ↓
              p24_l_emails_inbox

wa-web-collector pisze równolegle także do tabeli p24_whatsapp_messages (podgląd historii WA w et-operational-platform, whatsup-android-chat-puller#221/#222) — to osobny cel zapisu, niezwiązany z pipeline’em AI-to-inbox opisanym tutaj.

Uwierzytelnianie wywołań Supabase w n8n (#7576)

Węzły HTTP Request w wa-ai-to-inbox (Claim Messages, Process Tickets RPC) oraz resource-incident-analysis (Upsert incident) uwierzytelniają się credentialem n8n supabase-service-role-key (httpHeaderAuth, id ZNuDXmNs3nT58L6p) — nagłówek apikey wstrzykuje credential, a Authorization: Bearer jest budowany z $credentials.httpHeaderAuth.value. Nie używaj już {{ $env.SUPABASE_SERVICE_ROLE_KEY }} ani {{ $env.SUPABASE_SERVICE_KEY }} — te zmienne nie są ustawione w kontenerach n8n na bms-4 (ustawione jest tylko SUPABASE_URL), co było przyczyną awarii „Authorization failed” i braku zgłoszeń od 2026-06-25.

Co jest w pełni automatyczne (zero akcji)

Zbieranie wiadomości

Gdy numer kolektora zostanie dodany do nowej grupy WhatsApp — wiadomości z tej grupy automatycznie trafiają do Supabase.

wa-web-collector nasłuchuje na całej sesji WhatsApp Web urządzenia i upsertuje każdą pasującą wiadomość do whatsapp_messages ze statusem new. Kolektor konsultuje rejestr whatsapp_groups (flaga monitored) — szczegóły zakresu grup i zmienne WA_COLLECTOR_* w whatsup-android-chat-puller-operations.md.

Co zawiera każdy rekord w whatsapp_messages

Kolumna	Przykład	Źródło
`id`	`3EB0...@g.us_...`	WA message ID
`chat_id`	`120363411900921854@g.us`	JID grupy
`sender`	`4915785573196@c.us`	JID nadawcy
`sender_name`	`Radek`	Nazwa kontaktu z Baileys
`body`	`Mam usterkę monitora`	Treść
`has_media`	`true`	Czy jest zdjęcie/film (media → Wasabi)
`status`	`new`	Do przetworzenia przez AI

Co wymaga ręcznej akcji — rejestr grup

Tabela whatsapp_groups to rejestr do zarządzania (aliasy, flaga monitored). AI processing (n8n flow wa-ai-to-inbox) przetwarza tylko grupy z monitored = true.

Jeśli grupy nie ma w rejestrze → wiadomości mogą być zbierane, ale nie trafiają do p24_l_emails_inbox dopóki nie dodasz grupy i nie ustawisz monitored = true.

Jak dodać nową grupę (1-2 min)

Krok 1 — znajdź JID grupy

WAHA API już nie istnieje. Aktualne sposoby:

Opcja A — wyślij wiadomość testową w grupie; wa-web-collector upsertuje ją i chat_id pojawi się w whatsapp_messages (Supabase → Table Editor → filtr po created_at).
Opcja B — ustaw na kontenerze zmienną WA_COLLECTOR_DUMP_GROUPS i sprawdź logi kolektora, który wypisze znane grupy (JID + subject). Szczegóły w ops-doc kolektora.

Krok 2 — dodaj do rejestru

INSERT INTO whatsapp_groups (id, name, alias, monitored, description)
VALUES (
  '120363XXXXXXXXXX@g.us',   -- JID z kolektora
  'Nazwa grupy WA',           -- dokładna nazwa z WhatsApp
  'moj-alias',                -- krótki alias używany w platformie (unikalny)
  true,
  'Opis — opcjonalny'
);

Przez Supabase Dashboard → Table Editor → whatsapp_groups → Insert row.

Krok 3 — nic więcej

Wiadomości z tej grupy ze statusem new będą przetwarzane przez AI przy następnym uruchomieniu cron (co 5 min).

Scenariusze

Numer dodany do nowej grupy

Akcja	Automatyczne?
Wiadomości zbierane w `whatsapp_messages`	TAK — od razu (o ile kolektor działa)
Wiadomości przetwarzane przez AI	NIE — dopóki nie dodasz do `whatsapp_groups` z `monitored=true`
Dodanie do `whatsapp_groups`	ręcznie (SQL / Table Editor)

Chcesz chwilowo wyłączyć przetwarzanie jednej grupy (bez usuwania danych)

UPDATE whatsapp_groups SET monitored = false WHERE alias = 'awarie-dhl';

Wiadomości nie są przetwarzane / brak zgłoszeń

Sprawdź czy wa-web-collector żyje: docker ps | grep wa-web-collector na bms-4 (playbook: playbooks/wa-web-collector-recovery.md).
Sprawdź egzekucje wa-ai-to-inbox w n8n — węzeł Process Tickets RPC nie może zwracać „Authorization failed” (patrz sekcja uwierzytelniania wyżej, #7576).
Sprawdź rozkład status w whatsapp_messages — narastające processingError oznacza błąd w pipeline AI/RPC, nie w zbieraniu.
(#7626) Nieudane wywołanie Claude (limit użycia / wygasły OAuth / nie-JSON) nie tworzy już fałszywego ticketu „Blad parsowania odpowiedzi AI” ani nie oznacza wiadomości jako przetworzonej — batch jest zwalniany (release_wa_messages_batch: new z inkrementem processing_attempts, a po 5 próbach processingError), a wykonanie kończy się błędem. Gdy OBA konta Claude (claude-runner / claude-runner-2 na bms-4) są na limicie, wa_backoff_active wstrzymuje claimowanie przez ~30 min. Stan zatoru sprawdzisz przez SELECT * FROM wa_backlog_stats(); (wiek najstarszej new, liczniki). Szczegóły: infra-src/n8n-workflows/wa-ai-to-inbox.md.

Aktualny stan rejestru (2026-05-09)

Alias	Nazwa WA	JID
`zgloszenia`	et-operational-platform-zgloszenia	`120363411900921854@g.us`
`awarie-dhl`	Awarie dhl poczta	`4915224462971-1584089694@g.us`
`awarie`	Awarie	`4915253015583-1548075046@g.us`
`dp-eutingen-awarie`	Deutsche Post Eutingen Awarie	`120363401944773725@g.us`

Historia

2026-07-02 — WAHA (port 13000, NOWEB) zdekomisjonowane. Dawny przepływ WAHA → webhook n8n /wa-router → whatsapp_messages przestał działać; webhook wa-router pozostaje w n8n jako nieaktywny.
2026-10-04 — Baileys (wa-web-collector) wybrany jako jedyna wspierana ścieżka przechwytywania w czasie rzeczywistym (whatsup-android-chat-puller#175).
2026-10-08 (#7576) — naprawione uwierzytelnianie Process Tickets RPC (credential zamiast nieustawionego $env), przez co zgłoszenia znów trafiają do na_zgloszeniu_email.

p24-infra Docs

Explorer

whatsapp-group-monitoring