sender

sender

Сендер

SenderService приймає готового кандидата, вибирає інвайт і виконує автоматичну chat/mail-відправку. Сам online/new/all діалоги не скролить.

Джерела кандидатів

• Chathouse/Prime chat і mail — online-фаворити з isWhite, отримані із завершеного RU-online проходу; Prime за потреби точково отримує актуальний mail limit;
• Golden chat/mail — окремі FAV- і NEW-кандидати з поточного online-пулу без скролу діалогів.

SenderService приймає кандидата Chathouse/Prime лише з isWhite. Block або globalFavorite.senderIgnore відхиляє кандидата.

Сайтова ознака saved/bookmarked не визначає нашого фаворита. Вона може використовуватися лише як додаткове партнерське поле.

Дані

SenderCandidate {
  project
  tuId
  ruId
  online
  lastMessage
  chatLimit
  mailLimit
}
 
SenderHistory {
  tuId
  ruId
  channel
  inviteId
  externalMessageId
  sentAt
}

• inFlight: Set<TU+RU> — локальний захист;
• SenderHistory — затримки й порядок інвайтів;
• атомарний server claim TU+RU+channel — захист, коли одна TU відкрита у двох Electron.

Claim має короткий TTL і завершується результатом success/failure. Без успішного claim партнерський send не викликається.

Спільна відправка Chathouse/Prime

1. Взяти lock TU+RU.
2. Повторно перевірити TU/session, online, blocks, senderIgnore, favorite/white-list.
3. Повторно перевірити актуальні limits зі snapshot; застарілий snapshot не використовувати.
4. Перевірити затримку TU+RU+channel у SenderHistory.
5. Отримати перший невикористаний активний інвайт.
6. Якщо доступні chat limit, chat delay та chat invite — відправити chat.
7. Інакше, якщо доступні mail limit, mail delay та mail invite — відправити mail.
8. Після підтвердженого успіху:
   • записати SenderHistory та останній контакт;
   • збільшити лічильник інвайта й автоматичну дію оператора;
   • передати результат у DataSync;
   • завершити claim як success.
9. Після помилки завершити claim як failure; інвайт і його порядок не змінювати.

Mail не є fallback після невдалої chat-відправки. Він розглядається лише до send, коли chat зараз недоступний.

Поточна логіка Chathouse/Prime · as-is

TODO

Цільовий алгоритм роботи сендера з інвайтами ще не спроєктований. Нижче зафіксована поточна логіка; вибір і порядок інвайтів, затримки, додаткові повідомлення та умови скасування будуть перероблені.

Параметр	Chathouse	Prime
Chat delay	1 год	2 год
Mail delay	6 год	12 год
Chat додаткові повідомлення	до 2	—
Один RU з різних TU	до 5 TU/хв	окремого cap немає
Low-credit mail	spend 0–20; без фото	—
Звичайний Chathouse mail	spend 20+; фото дозволено	—
Chat-текст	тільки латиниця	окремого правила немає
Mail media	фото	до 10 фото + до 10 відео

Додаткові повідомлення Chathouse · as-is

Після основного chat можуть бути до двох відкладених повідомлень.

Перед кожним:

1. Отримати останні повідомлення діалогу.
2. Переконатися, що попереднє sender-повідомлення досі останнє.
3. Перевірити відповідний text/sticker/photo limit.
4. Для photo повторно перевірити spend 20+.
5. Відправити й окремо записати успішний результат.

Отже кожне дослання додає до 1 history + 1 send партнерського запиту.

Цільовий ланцюжок ще треба спроєктувати: точний порядок і затримки, скасування після reply/manual send/block/offline, поведінка після reconnect/restart і збереження незавершеного стану.

Golden chat

Golden не отримує готовий dialog snapshot. Кандидати беруться з online-пулу:

1. white-list favorite з наступним невикористаним FAV-інвайтом;
2. новий white-list favorite;
3. повтор FAV-інвайта після 3 год;
4. online RU з окремого Golden NEW-пулу та наступним NEW-інвайтом;
5. новий online RU у NEW-пулі;
6. повтор NEW-інвайта після 3 год.

Для кожного кандидата повторно перевіряються block, контактні дані, тимчасовий stop і senderIgnore.

Chat queue

На одну TU:

• між send-командами не менше 5.5 с;
• одночасно одна sender-відправка;
• ручна відправка має пріоритет і може зарезервувати наступний слот;
• socket confirmFromClient підтверджує успіх одразу;
• після confirmFromServer очікується ще 1 с;
• limit, limitSecond, offlineUser завершують спробу помилкою;
• без відповіді за 10 с спроба вважається невдалою.

Лише після такого підтвердження оновлюється SenderHistory. П’ять послідовних невідомих помилок у поточному Electron зупиняють TU runner; у новій програмі це має стати явним degraded-станом сендера, а не тихою зупинкою.

Golden mail

Golden mail sender працює partner batch-процедурою:

1. Перевірити FAV/NAF-кандидатів; якщо кандидатів немає — NEW/FANM-кандидатів.
2. Відфільтрувати blocks, sender-ignore, контакти, sender black-list та історію.
3. Взяти до 10 RU.
4. Запустити command='send'.
5. Раз на 6 с читати command='status', доки не буде end або limit.
6. Записати success окремо для кожного RU.

Поточні цикли інвайтів:

• FAV/NAF — один раз на день;
• NEW/FANM — один раз на 7 днів.

UNREAD запускає точкове відкриття mail history; Duplicated пропускає RU. Технічний exception зараз додає RU у sender black-list. У цільовій логіці постійний block ставиться лише за підтвердженою відповіддю API; невідома помилка має retry/backoff і не змінює BlockService.

Фіксація відповіді RU

Після успішної відправки Sender зберігає inviteId, partner externalMessageId і час. Коли socket або прохід діалогу приносить вхідне повідомлення:

1. Знайти sender-відправку за externalMessageId у впорядкованій історії діалогу.
2. Переконатися, що наступне повідомлення надійшло від RU, а між ними немає іншого повідомлення TU.
3. Передати факт відповіді через DataSync у SenderAnalyticsService.

Electron лише знаходить зв’язок відправлення з відповіддю. Сервер idempotent-зберігає результат і будує аналітику.

Помилки

Результат	Дія
timeout / network / 5xx	не рухати інвайт; звільнити claim; retry з backoff
rate limit	зупинити канал TU до retryAt
RU offline	оновити online точково; без retry у цьому проході
confirmed blocked	BlockService.update і закриття тасків пари
invalid invite/media	позначити помилку конфігурації TU; інших RU не блокувати
success	історія, контакт, дія оператора, DataSync

Запити

Скрол-запитів SenderService не додає.

• основний chat/mail success — один chat або mail send;
• Chathouse додатково: до 2 × (history + send);
• Golden mail batch: 1 send + N_status;
• API-перевірки кандидата належать сервісу, який сформував snapshot.

Зв’язки

• Читає: Invites, FavoriteService, BlockService, RUOnlineService, SenderHistory.
• Отримує кандидатів: RU Online, RU All Dialogs і Golden runtime-state.
• Віддає результат: останній контакт, дії оператора, DataSync та UI-стан сендера.