operator-actions

Сервіс обробки дій оператора

Пише дії оператора у стрім, стежить за активністю (кік при 10 хв простою) і віддає стрім на наш сервер, з якого сервер відновлює онлайн оператора. Наше апі, однаково для всіх проектів.

Інтервал

60 с — перевірка активності. Синк стріму на сервер — теж 60 с (через збереження даних).

Логіка

  1. Дії — на ручну відправку пишемо рядок у локальний стрім operator_actions { action, timestamp }. Типів фактично два: chat і mail (фото/медіа теж chat). Автодії сендера рахуються окремо (таблиці chat_senders / mail_senders, поле initiatorType User/Sender).
  2. Активність / кік — остання дія оновлює lastActivityTime; перевірка щохвилини; 10 хв без дії → діалог «Неактивність» + за 30 с app.quit() (повне закриття, не логаут).
  3. Онлайн оператора — у клієнті не рахуємо. Стрім дій батчем іде на сервер (60 с), і сервер відновлює сесії онлайну (дії в межах 5 хв = одна сесія).

Дані / стан

Найважливіше, що тримаємо (як у коді)

  • Дія{ action: 'chat' | 'mail', timestamp }
  • Автодія сендера — окремо, { initiatorType: User | Sender, type }
ДаніДеОновлення
Стрім дій (operator_actions)локальна SQLiteна кожну ручну відправку; синк батчем 60 с → видалення після ack
lastActivityTimeпам’ятькожна дія; кік при 10 хв
Sleep-стан операторанаш редіс (сервер)маркери sleep:on/off; TTL 12 год
Онлайн операторасервер (зі стріму)не в клієнті; правило 5-хв сесій

Нюанси

  • «Дії по типах» фактично = chat / mail (медіа/фото теж chat); окремих типів інвайт/таск/стікер нема (розширення — при потребі).
  • Автодії сендера — окремі таблиці, не в стрімі дій; розрізнення по initiatorType.
  • Онлайн оператора — серверний конструкт зі стріму дій, а не окреме поле в клієнті; редіс тримає sleep-стан, не «останній онлайн».
  • Sleep-режим у клієнті зараз вимкнений (маркери пишуться, але старт закоментований).
  • зап/хв — наше апі (стрім батчем 60 с).

Зв’язки