Quartz 4

socket-events

6 min readBohdan Derkach

socket-events

Обробка socket-подій

Один pipeline для партнерських socket-подій. Task Factory, FavoriteService, BlockService та UI не розбирають проєктні payload напряму.

Наш Stack socket керує оператором/TU та live-view і сюди не входить.

Основні сигнали

✓ — подія і payload підтверджені; △ — подія є, але payload, повноту або обробку треба перевірити; — — корисної socket-події немає.

СигналGoldenChathousePrime
Повідомлення✓✓✓
Лист—△✓
Прочитання повідомлення—△✓
Typing—✓✓
Зміна chat/mail limits—✓✓
RU online/offline—△✓
Block/unblock—△✓
Нотифікація для тасків—✓—
Створення діалогу——△

Структура в коді

Для кожного проєкту залишається свій socket-клієнт і parser: він підключає конкретну TU, робить reconnect, перевіряє проєктний payload і створює спільний SocketEvent.

Далі подія передається конкретним споживачам за type. Це може бути звичайний typed event bus, а не окремий великий сервіс.

SocketEvent {
  eventId
  project
  tuId
  ruId?
  type
  occurredAt
  data
}

Дедуп:

  • Golden — socket message id;
  • Chathouse — message.id, notification.id або fingerprint action + RU + time;
  • Prime — id верхнього envelope;
  • fallback-fingerprint використовується лише коли стабільного id немає.

Реєстр socket-подій

Кожен проєкт логуватиме унікальні типи та форми payload за механікою Prime socketTypeRegistry:

  1. Сира подія потрапляє в registry до allow-list, parser та будь-якого раннього return.
  2. Ключ містить проєкт, type/action, відсортований набір полів і підтип повідомлення або notification, якщо він є.
  3. Для нового ключа зберігаються час, форма та один приклад payload. Повторні події I/O не створюють.
  4. Нова форма вже відомого типу також вважається новим ключем.
  5. Registry працює постійно, щоб після змін партнерського API невідомі події та поля не губилися.

Невідомі події не запускають бізнес-логіку до перевірки їх payload.

Якщо socket є лише сигналом і даних недостатньо, точковий запит робить конкретна логіка, яка володіє цим API. Socket pipeline сам API не викликає.

Golden

Формат: { method, toId, message }, де message переважно є JSON-масивом.

ping і clearNonSendMessages описані в enum, але цільова бізнес-обробка для них не потрібна.

Chathouse

Формат Centrifuge publication: { action, ...payload }.

Відомі та потрібні

Невідомі події

notification.type: visit, message, like, mutual like, profiles, added as favourite, inmail, credits, online now, recent purchase, connection reminder, gift та icebreaker moderation. Для тасків зараз важливі лише ONLINE_NOW (16) і RECENT_PURCHASE (17).

Поточний код фактично обробляє send, typing, new/repeat_notification і limit_changed. Решту actions треба пропустити через спільний registry та перевірити на живих подіях.

Prime

Формат envelope: { id, type, data?, email?, dateExpired }.

Відомі та потрібні

Відомі допоміжні події

Треба перевірити

  • виправити Blocked: payload плоский, а поточний parser читає вкладене data.message;
  • перевірити chat_DialogCreated як тригер OpenLimits;
  • додати в parser побачений наживо підтип MessageSent.reply_newsfeed_post;
  • накопичувати нові типи та нові форми відомих типів через registry.

Prime вже має живий registry форм станом на 20.07.2026; він є основним джерелом описаних payload. Типізовані підтипи MessageSent: message, photo, virtual_gift, wink, likephoto, sticker, like_newsfeed_post.

Точкові перевірки після socket

Socket pipeline: 0 партнерських запитів.

Ціль — спочатку використовувати свіжі дані відповідного сервісу. Точковий запит робиться лише коли socket-подія несе недостатньо даних або наявний стан застарів.

Graph View

Backlinks