Background jobs в.NET: retry есть, а exactly‑once никто не завозил

[Gromilo]

Фреймворк видит exception. Бизнес видит второй счет клиенту. Разница небольшая, примерно как между «инцидент» и «созвон через 10 минут».

Я всё понимаю, просите нейронку писать покороче, в информационном стиле. Но поиграйте с промтами, невозможно же читать такую рубленную подачу.

На цитате выше я сломался и бросил статью

[pabel0071]

Спасибо, замечание принимаю. Смысл фразы был в том, что retry работает с техническим failure, а для бизнеса важен возможный дубль операции. Но подача правда получилась слишком "цитатная". Поправлю текст, чтобы читалось спокойнее и без ощущения сгенерированной вставки.

[mogilovo]

Интересное, но не проработанное. Интересно было бы приведение статьи к сагам или acid гарантиям типового функционала для сравнения механизмов. Касательно логгирования есть стандарты и они довольно известные. А вот обсервабилити в разных вариантах использования и их поддержки в инструментах конечно тоже были бы интересны.

Как начинание похвально. Если использовался ИИ то считаю что автору не хватает знаний использования потому что ИИ описал довольно посредственную статью.

P. S. Сейчас было бы интересно и наверное актуально аналоги в РФ которые доступны текущих в рамках. А еще интересен вопрос почему довольно часто пишут свои вокреры а не используют типовый даже от MS

[Veantm]

А как насчёт https://tickerq.net/

[totsamiynixon]

Ответ на не поставленный вопрос - идемпотентность.

Если идемпотентно - ретраить безопасно. Если не идемпотентно - надо думать, лучше заретраить или лучше не ретраить.

Если есть Process Manager, то вероятно есть и Process State - туда можно буквально записывать после каждого шага, какой выполнился, а какой нет, и при ретрае скипать выполненные шаги или {представьте сюда свою логику}.

В общем проблеме лет столько же, сколько программированию и на все вопросы уже есть ответы.

[Gromilo]

А потом у тебя какая-нибудь неидемпотентная интеграция с системой, которую не ты писал и никак повлиять не можешь :)