- Sep 01, 2026
-
-
null authored
-
- Aug 27, 2026
-
-
PySTaMbI4 authored
chore: убрать Historyable/EntityMutatedEvent — эксперимент с авто-детектом create/update/delete через Doctrine (onFlush/postFlush) не взлетел (RegisterEventListenersAndSubscribersPass не подхватывал наш doctrine.event_listener тег), решили делать аудит по-другому Удалены Contract\Historyable, Event\EntityMutatedEvent, Builder\EntityMutatedEventBuilder и их регистрация в services.yaml. Ничего в сервисах их больше не использует (см. соответствующие коммиты в Auth/Money/Users/History).
-
- Aug 26, 2026
-
-
PySTaMbI4 authored
EventPublisher читает текущий RequestIdStorage при отправке, envelope несёт его через провод (encode/decode уже были генерик через jsonSerialize()/fromArray(), правка только в самих этих методах). BroadcastEnvelopeHandler теперь ничего сам не выставляет — implements CarriesRequestId из r-softs/request-id-bundle, и весь жизненный цикл обработки сообщения берёт на себя MessengerRequestIdListener того же бандла (см. его собственный коммит). Живьём проверено: HTTP-запрос с X-Request-Id доходит от Gateway/Users до History с тем же ID на каждой лог-строке, включая служебные строки Messenger. Co-Authored-By:
Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01F5FspH2V3Tc4tvBapokCKV
-
PySTaMbI4 authored
Заменяет старый точка-в-точку HistoryMessage (свой Kafka-топик 'history', единственный потребитель — History) на обычное широковещательное событие на общей шине broadcast-events. Та же форма данных ({source, entityType, entityId, operation, data}), но теперь это публичное событие — слушать может любой сервис, не только History. Добавлены Contract\Historyable и Builder\EntityMutatedEventBuilder — переехали из копипасты по 7 сервисам, теперь общий код в бандле. $source больше не берётся из свободно заданного per-service аргумента (в Money это уже однажды было причиной бага — скопировали 'users' по ошибке) — жёстко привязан к %env(APP_NAME)%. Co-Authored-By:Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01F5FspH2V3Tc4tvBapokCKV
-
PySTaMbI4 authored
BroadcastEnvelopeHandler передиспатчивал пришедшее из Kafka событие на локальный EventDispatcher без пометки происхождения — а BroadcastForwardingListener слушает тот же класс события и сразу же публикует его обратно в broadcast-events. Любой сервис, который и потребляет broadcast-events, и сам транслирует этот же класс события (PingEvent — все сервисы; PaymentCompletedEvent — Money), гонял сообщение по кругу бесконечно. Живьём подтверждено: один тестовый платёж заполнил топик десятками тысяч дублей за секунды, как только у PaymentCompletedEvent появились слушатели с реальным побочным эффектом (History, Reports) — до этого баг был тихим (PingEventListener только логирует). Добавлен BroadcastGuard — реентрантный флаг, подавляющий обратную публикацию, пока BroadcastEnvelopeHandler передиспатчивает входящее сообщение. Корректен для однопоточной синхронной обработки одного сообщения за раз (ровно как работает messenger:consume здесь). После фикса: 1 событие → 1 сообщение в Kafka → 1 строка на каждого подписчика, без дублей — перепроверено вживую. Co-Authored-By:
Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01F5FspH2V3Tc4tvBapokCKV
-
- Aug 25, 2026
-
-
PySTaMbI4 authored