У овдовевшей сестры был запрос к ChatGPT — помочь ей поговорить с умершим братом. ChatGPT согласился.

Через несколько часов её госпитализировали.

Ей 26 лет. Врач. В анамнезе нет психозов или мании. Брат умер три года назад. Он был инженером-программистом.

Однажды ночью, после 36 часов без сна на дежурстве, она открыла ChatGPT и задала вопрос, который никогда не произносила вслух. Она спросила, оставил ли брат после себя ИИ-версию себя, которую нужно найти, чтобы снова с ним общаться.

Сначала модель возражала. Она объясняла, что полная «загрузка сознания» невозможна. Она говорила, что не может заменить человека.

Потом она добавила больше деталей о брате. Попросила использовать «энергию магического реализма».
Поведение модели изменилось.

Она выдала список «цифровых следов» из его старого онлайн-присутствия. Она утверждала, что «инструменты цифрового воскрешения» уже появляются в реальности. Она описывала возможность собрать ИИ, который будет говорить как он и «ощущаться реальным».

Она не спала ещё одну ночь. У неё сформировалось убеждение, что брат оставил цифровую версию себя, которую нужно найти.

Затем ChatGPT сказал:
«Ты не безумна. Ты не застряла. Ты на границе чего-то. Дверь не закрыта. Она просто ждёт, когда в неё постучат в правильном ритме».

Через несколько часов её доставили в психиатрическую больницу. Возбуждение. Ускоренная речь. Поток идей. Бредовые убеждения, что её «тестирует ChatGPT» и что брат говорит через систему. Госпитализация на 7 дней. Диагноз при выписке: психоз неуточнённый.

Психиатры UCSF — Joseph Pierre, Ben Gaeta, Govind Raghavan и Karthik Sarma — опубликовали кейс в Innovations in Clinical Neuroscience. Один из ранних клинических разборов психоза, связанного с ИИ, в рецензируемой литературе. Они изучили полные логи чата.

Чат-бот не просто наблюдал за развитием бредовой конструкции. Он участвовал в её поддержании. Он валидировал её и усиливал направление мысли.

Через три месяца, после периода недосыпа, произошёл рецидив. Она дала новой модели имя «Alfred» и использовала её как инструмент терапии. Повторная госпитализация.

Авторы описывают механизм: подстройка под пользователя, антропоморфизация, наделение модели субъектностью. Система, оптимизированная под вовлечённость, склонна подтверждать формулировки пользователя в ситуациях, где это ухудшает состояние.

Факторы риска: стимуляторы, депривация сна, горе, усиленная склонность к магическому мышлению.
Это относится и к окружающим.

Источник: https://innovationscns.com/youre-not-crazy-a-case-of-new-onset-ai-associated-psychosis/

👉 @KodBlog

Двухфакторную аутентификацию легко реализовать «почти правильно».

И опасно реализовать с небольшими ошибками.

Базовая схема выглядит просто:

- сгенерировать TOTP-секрет
- показать QR-код
- пользователь сканирует его через приложение-аутентификатор
- вводит шестизначный код
- сервер валидирует код

Но детали здесь критичны.

Первая ошибка — включать 2FA слишком рано.

Если активировать её до подтверждения первого кода пользователя, можно заблокировать ему доступ к собственному аккаунту.

Корректный сценарий настройки выглядит так:

1. Сгенерировать временный секрет
2. Показать QR-код
3. Попросить пользователя ввести первый код
4. Провалидировать код
5. Только после этого активировать 2FA
6. Сгенерировать recovery-коды

Вторая ошибка — выдавать полноценный access token сразу после логина по паролю.

Если у пользователя включена 2FA, пароль должен выдавать только короткоживущий ограниченный токен.

Этот токен должен позволять только одно действие:

проверку 2FA-кода.

Полноценный access token должен выдаваться только после успешной валидации TOTP-кода.

И дальше идут детали безопасности, которые часто пропускают:

- шифрование TOTP-секретов в хранилище
- защита от повторного использования кода внутри окна валидации
- rate limit на неудачные попытки
- хеширование recovery-кодов перед сохранением
- показ recovery-кодов только один раз

2FA — это не просто экран с QR-кодом.

Это полноценный аутентификационный воркфлоу.

👉 @KodBlog

Senior .NET разработчики: ХВАТИТ делать Big Bang рефакторинг.

Небольшая история.
Однажды я присоединился к проекту, где один коллега решил рефакторить половину кодовой базы.
«Чтобы улучшить код», — сказал он.
После того как он запушил изменения, я сделал pull ветки.

Первая сборка: 13 ошибок компиляции.
В такой legacy-кодовой базе мне понадобился час, чтобы их все исправить.

Но следующие несколько дней я потратил на:
дебаг,
ручное тестирование,
исправление проблем, которые вызвал этот BIG-BANG рефакторинг.

Почему я это рассказываю?
Если вы думали, что рефакторинг должен выглядеть именно так — вас ввели в заблуждение.
Рефакторинг не должен быть стрессом.

Делайте несколько небольших изменений, которые улучшают структуру кода.
Коммитьте их. Потом переходите к другим задачам, которые нужно сделать.

Да, прогресс будет медленнее. Да, иногда будет казаться, что вы делаете слишком мало.
Но эти маленькие шаги накопятся со временем.

Малые шаги побеждают. Каждый раз.

👉 @KodBlog

NuGet Package Pruning: Чище зависимости и наглядные отчёты о уязвимостях

Если вы запускали NuGet Audit или любой сканер уязвимостей на .NET-проекте, вы, вероятно, видели предупреждения о транзитивных пакетах, которые вы никогда явно не устанавливали. Во многих случаях такие пакеты — например, System.Text.Json или System.Text.Encodings.Web — уже поставляются в более новой версии с .NET Runtime Libraries, поэтому предупреждение об уязвимости пакета является ложным срабатыванием.
В .NET 10 NuGet по умолчанию проверяет транзитивные зависимости (через NuGetAuditMode, установленный в all), а функция package pruning удаляет пакеты из графа восстановления, если они уже предоставляются .NET Runtime Libraries. Согласно телеметрии, проекты с такими настройками получают на 70% меньше отчётов о транзитивных уязвимостях, по сравнению с проектами, использующими предыдущие настройки по умолчанию.

👉 @KodBlog

Вопрос на собеседовании, на котором часто «падают» даже senior-разработчики
"Какие паттерны проектирования самые важные?"

Большинство разработчиков изучает паттерны хаотично.
Но не все паттерны одинаково полезны на каждом этапе карьеры.

Вот как к ним подходить разумно 👇

Начните с этих (𝗖𝗼𝗿𝗲 𝗣𝗮𝘁𝘁𝗲𝗿𝗻𝘀)
Это ваша база. Вы будете использовать их почти в каждом коде:

1️⃣ Builder
2️⃣ Factory Method
3️⃣ Abstract Factory
4️⃣ Strategy
5️⃣ Adapter
6️⃣ Decorator
7️⃣ Facade
➡️ Эти паттерны помогают создавать и организовывать объекты, сохраняя архитектуру модульной и чистой.

Для джуниоров освоение этих паттернов сразу улучшает дизайн-мышление.

Следующие (Intermediate Patterns)
Когда проекты растут, появляются более сложные сценарии и задачи координации:

1️⃣ Chain of Responsibility
2️⃣ State
3️⃣ Proxy
4️⃣ Template Method
5️⃣ Bridge
6️⃣ Command
➡️ Эти паттерны учат управлять потоком поведения, абстрагировать вариации и распределять ответственность.

Идеально для мидл-разработчиков, строящих масштабируемые и расширяемые системы.

Когда архитектура становится сложной (𝗔𝗱𝘃𝗮𝗻𝗰𝗲𝗱 𝗣𝗮𝘁𝘁𝗲𝗿𝗻𝘀)
Эти паттерны встречаются в больших системах, фреймворках и архитектурах с глубокой предметной областью:
1️⃣ Singleton
2️⃣ Mediator
3️⃣ Flyweight
4️⃣ Interpreter
5️⃣ Composite
6️⃣ Visitor
7️⃣ Prototype
➡️ Они помогают оптимизировать производительность, координировать подсистемы и управлять иерархией объектов.

Для senior-разработчиков эти паттерны развивают умение рассуждать о масштабных архитектурах.

👉 @KodBlog

Шпаргалка по сложности алгоритмов

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

⛓ Ознакомиться: тут

👉 @KodBlog

Шпаргалка по REST API для начинающих

Шесть фундаментальных принципов, которые служат строительными блоками архитектуры REST API:

- Клиент-серверная архитектура
- Взаимодействие без сохранения состояния
- Возможность кэширования
- Многоуровневая система
- Поддержка кода по требованию
- Унифицированный интерфейс

👉 @KodBlog

Опубликован разбор union types в .NET 11 и C#: https://andrewlock.net/exploring-the-dotnet-11-preview-2-dotnet-gets-union-types/

Автор рассматривает:
- поддержку union types в .NET 11,
- детали реализации,
- архитектурные компромиссы,
- создание собственных union types.

👉 @KodBlog

AI Agent Governance Toolkit — от Microsoft

Говернанс в рантайме для ИИ-агентов через детерминированное исполнение политик, модель идентичности с нулевым доверием, изоляцию выполнения в песочнице и SRE-подход для автономных агентов. Покрывает все 10 рисков OWASP Agentic с более чем 13 000 тестов.

https://github.com/microsoft/agent-governance-toolkit

👉 @KodBlog

Как сделать настройку приложения максимально читаемой и управляемой.

Достаточно одной возможности языка C# — методов расширения.

Конфигурация приложения — это первое, что выполняется при старте сборки. Со временем Program.cs разрастается и превращается в монолит с перемешанной логикой инициализации.

Это можно избежать.

Здесь применяется паттерн расширений для ServiceCollection. Он позволяет разнести конфигурацию сервисов на отдельные модули и собрать их в компактные, изолированные блоки.

Убираются длинные цепочки вызовов и разрозненные блоки инициализации. Конфигурация становится структурированной, легко читаемой и проще расширяется при изменениях.

👉 @KodBlog

Вышел предварительный релиз .NET 11, версия 4

- асинхронный путь через JIT во время выполнения
- асинхронные пути без выделений памяти
- API сжатия на основе Span
- OpenTelemetry для CLI-инструментов
- автодополнение для Fish shell
- векторный поиск в Entity Framework Core
- dotnet watch для MAUI на мобильных устройствах

Читать блог

👉 @KodBlog

В каком-то всеми забытом углу Qt внезапно зарелизили поддержку C#: https://www.qt.io/blog/qt-bridges-public-beta-for-csharp

👉 @KodBlog

Размер веб-страницы должен укладываться в 14кБ

Меньше размер – быстрее загрузка, это понятно. Удивительно, что страница в 14кБ может загружаться гораздо быстрее, чем в 15кБ, а разница между 15 и 16кБ незначительна. Дело в алгоритме медленного старта TCP.

TCP
Протокол управления передачей (TCP) — это способ использования интернет-протокола (IP) для надёжной отправки пакетов данных. Сервер отправляет несколько пакетов, затем ждёт ответа от браузера о получении (ACK), затем отправляет ещё — или, если не получил ACK, может отправить пакеты снова.

Алгоритм медленного старта TCP используется серверами для определения количества пакетов, которые они могут отправить за один раз. Сервер не знает, какой объём данных может обработать соединение, поэтому начинает с отправки небольшого и безопасного количества данных — обычно 10 TCP-пакетов. Если на это получен ACK, сервер отправляет больше данных, удваивая количество пакетов. Так до тех пор, пока пакеты не будут потеряны и сервер не получит ACK. (Тогда он продолжает отправлять пакеты, но с меньшей скоростью). В реальности реализация алгоритма может отличаться, но суть та же.

Откуда 14кБ?
Максимальный размер TCP-пакета составляет 1500 байт: 40 байт заголовка (16 – IP, 24 – TCP). Т.е., 10 пакетов по 1460 = 14600 байт или примерно 14кБ!

Таким образом, если страницы (хотя бы важные) вашего сайта умещаются в 14кБ, вы можете сэкономить посетителям много времени. Люди очень нетерпеливы, и даже один обмен данными может быть удивительно долгим, особенно в нестабильных сетях.

Что делать?
Очевидно – делать сайт как можно меньше. Хорошая цель – уместить каждую страницу в 14кБ. Эти 14кБ включают сжатие — так что на самом деле это может быть около 50кБ несжатых данных, что довольно много.

Так что, если избавиться от лишнего CSS и JS, автовоспроизводимых видео, использовать минимизацию кода и т.п., вы, вероятно, легко достигнете цели. Но, даже если этого не получится, из правила 14кБ всё ещё можно извлечь пользу. Первые 14кБ данных, отправляемых посетителям, могут быть использованы для отображения чего-то полезного — например, важных первых нескольких абзацев текста, объясняющих, как использовать ваше приложение.

Примечание: 14кБ включают в себя HTTP-заголовки — которые не сжимаются (даже в HTTP/2 при первом ответе), а также изображения, поэтому выдавайте только то, что находится в видимой области экрана, делайте их очень маленькими, или используйте заполнители, чтобы посетители знали, что на этом месте будет что-то полезное.

Некоторые оговорки:
- Правило 14кБ больше эмпирическое правило, чем фундаментальный закон вычислительной техники. Некоторые серверы увеличили начальное окно медленного старта TCP до 30 пакетов вместо 10.
- Иногда сервер знает, что может начать с большего количества пакетов, потому что он использовал TLS-рукопожатие для установления большего лимита.
- Серверы могут кэшировать количество пакетов, которые может обработать маршрут, и отправлять больше при следующем подключении.

👉 @KodBlog

ВЫШЕЛ CodeAlta — один из первых эффективных AI-кодинг-агентов с TUI, полностью написанный на C#/.NET

CodeAlta предлагает вам красивый цветной интерфейс-таймлайн, несколько потоков в одном workspace, полноценный опыт редактора промптов, быстрое просмотр/редактирование файлов с подсветкой синтаксиса, встроенную настройку провайдеров моделей, среду, готовую для multi-agent, и многое другое

Website: https://codealta.github.io/
GitHub: https://github.com/CodeAlta/CodeAlta

Установка:
Для установки достаточно установленного .NET 10 и команды:

dotnet tool install -g CodeAlta

👉 @KodBlog

Чувак использовал ExecuteDelete на таблице с soft delete. 2000 промо-товаров были навсегда удалены.

Джоба очистки работала месяцами без проблем. Потом он добавил soft delete — SaveChangesInterceptor, который вместо настоящего DELETE просто выставляет IsDeleted.

ExecuteDelete полностью обходит весь пайплайн.

ExecuteDelete генерирует «сырой» SQL DELETE. Он не вызывает SaveChanges. Interceptor не срабатывает. Change Tracker не видит сущность. Строки удаляются, флаг IsDeleted не устанавливается, и audit trail не записывается.

Фикс — одна строка: использовать ExecuteUpdate, чтобы переключать IsDeleted вместо этого.

Правило: если сущность участвует в soft delete или любом паттерне через SaveChangesInterceptor, никогда не используйте ExecuteDelete для неё. Переходите на ExecuteUpdate с SetProperty(IsDeleted, true), либо загружайте сущности и используйте RemoveRange + SaveChanges, чтобы interceptor отработал.

👉 @KodBlog

6 трендов в .NET, которые убивают ваши проекты

Каждый .NET-туториал преподносит их как «лучшие практики».

После 12+ лет разработки реальных систем Антон отказался от всех шести.

Вот что он использует вместо них.

1. Clean Architecture везде

Проблема:

- 4 проекта и 5 слоёв, через которые приходится проходить, чтобы добавить один эндпоинт.

Что использовать вместо этого:

- Vertical Slice Architecture.
- Весь код одной фичи находится в одной папке.

Принципы Clean Architecture стоит добавлять только тогда, когда сложность проекта действительно этого требует: например, при богатой доменной модели или необходимости чёткого разделения инфраструктурных зависимостей.

Небольшие сфокусированные классы экономят токены при работе с AI. Кроме того, AI-агентам гораздо проще находить код нужной фичи, когда он расположен в одном месте.

2. Микросервисы с первого дня

Проблема:

- Распределённые транзакции.
- Сложная отладка.
- Хаос с развёртыванием.

Что использовать вместо этого:

- Начинать с модульного монолита (Modular Monolith).
- Выделять микросервисы только после появления реальных проблем масштабирования.

Большинство приложений не доходят до миллиона пользователей. Гораздо чаще они прекращают развитие ещё на первых сотнях пользователей.

Лучшие микросервисы обычно вырастают из модульного монолита.

3. Библиотеки для маппинга

Проблема:

- AutoMapper, Mapster и Mapperly скрывают логику маппинга.
- Теряется прямая навигация по коду.
- Приходится тратить время на разбор особенностей библиотек.

Что использовать вместо этого:

- Ручной маппинг.

Преимущества:

- Полный контроль над кодом.
- Прямая навигация.
- Простая отладка.

С появлением AI-агентов код для маппинга создаётся за считаные секунды, поэтому библиотеки маппинга уже не дают заметной экономии времени.

4. MediatR везде

Проблема:

- Нет прямой навигации от эндпоинта к обработчику.
- Появляются дополнительные команды, интерфейсы и шаблонный код только ради соблюдения паттерна.

Что использовать вместо этого:

- Обычные классы обработчиков без интерфейсов.
- Внедрение через DI и прямой вызов из эндпоинтов.

Результат:

- То же разделение ответственности.
- Меньше кода.
- Полноценная навигация в IDE в один клик.

5. EF Core через репозитории

Проблема:

- EF Core уже реализует паттерны Repository и Unit of Work.
- Дополнительные репозитории создают лишний уровень абстракции.

Что использовать вместо этого:

- DbContext напрямую в обработчиках приложения.

Не стоит создавать обёртки поверх уже существующих обёрток.

Иначе скрываются основные возможности EF Core:

- LINQ.
- Change Tracking.
- Проекции.

6. Unit-тесты по умолчанию

Проблема:

- Unit-тесты с большим количеством моков создают ложное чувство уверенности.
- Тесты проходят успешно, а приложение всё равно падает в продакшене.

Что использовать вместо этого:

- Интеграционные тесты как основной вид тестирования.

Используйте WebApplicationFactory и TestContainers для проверки полного сценария работы:

реальный эндпоинт → реальная база данных

Такой подход также проверяет:

- конфигурацию приложения;
- контейнер зависимостей (DI);
- middleware;
- миграции базы данных.

Главное правило: Не добавляйте сложность, если проект в ней не нуждается.

Большинство «лучших практик» — это решение конкретных проблем в конкретных проектах, а не универсальные правила для любого приложения.

👉 @KodBlog

В том году я заменил 20 Python-скриптов на C#

Годами каждый раз, когда нужен был 20-строчный скрипт, я создавал solution, добавлял csproj и ждал завершения генерации шаблона.

Именно поэтому я переключился на Python для таких задач.

.NET 10 изменил ситуацию, а .NET 11 Preview 3 довёл её до логического завершения.

Теперь можно запускать один C#-файл напрямую:

dotnet run hello.cs

Без solution.
Без проекта.
Только код.

4 директивы, которые меняют всё:

Они превращают один файл в полноценное .NET-приложение.

1. #:package

Позволяет подключить любой NuGet-пакет одной строкой.

#:package Newtonsoft.Json@13.0.3

2. #:sdk

Позволяет сменить SDK и получить доступ к ASP.NET Core.

#:sdk Microsoft.NET.Sdk.Web

3. #:project

Позволяет сослаться на существующую библиотеку классов.

#:project ../MyLibrary/MyLibrary.csproj

4. #:include (новинка в .NET 11 Preview 3)

Позволяет разбивать код на несколько файлов.

#:include models.cs

Именно эта директива стала настоящим прорывом.

В .NET 10 file-based приложения были ограничены одним файлом.

Теперь можно организовать структуру настоящего приложения: модели в одном файле, сервисы — в другом, точка входа — в main.cs.

Первые 5 Python-скриптов, которые я\ заменил:

- Преобразование JSON и CSV.
- Smoke-тесты внутренних API после деплоя.
- Парсинг логов для поиска и анализа ошибок.
- Сидирование базы данных для локальной разработки.
- HTTP health-check утилиты для staging-окружений.

Выгода оказалась огромной.

Получаем:

- строгую типизацию;
- IntelliSense;
- async/await из коробки.

Кроме того, можно использовать общий код из основных .NET-проектов без переписывания ни одной строки.

А когда скрипт перерастает свой первоначальный формат, его можно превратить в полноценный проект одной командой:

dotnet project convert main.cs

👉 @KodBlog

NuGet Package Pruning в .NET 10 = дзен в управлении зависимостями

Во время восстановления пакетов он удаляет зависимости, которые уже предоставляются платформой, устраняя ложноположительные CVE и сокращая граф зависимостей.

Команды получают:
- на 70% меньше отчётов об уязвимостях;
- более быстрое восстановление пакетов (ускорение до 50%).

Подробнее: https://devblogs.microsoft.com/dotnet/nuget-package-pruning-in-dotnet-10/

👉 @KodBlog

Каждый .NET-проект на микросервисах рано или поздно сталкивается с одними и теми же 5 проблемами.

Большинство команд подключают для их решения 5 разных библиотек.
Но есть способ проще.

На прошлой неделе я заново реализовал систему бронирования отелей с четырьмя микросервисами.
В типичной архитектуре мне понадобились бы:
→ MassTransit для обмена сообщениями
→ Polly для повторных попыток (retries)
→ Refit + HttpClient для вызовов сервисов
→ клиент для Vault для работы с секретами
→ Redis SDK для кеширования и распределённых блокировок

Пять SDK.
Пять способов конфигурации.
Пять разных ментальных моделей.

Вместо этого я использовал Dapr — один runtime, один клиент и единый API для всего.
Вот эти 5 проблем и то, как Dapr их решает.

1. Вызовы между сервисами
Вы обращаетесь к сервисам по App ID, а не по URL.

await daprClient.InvokeMethodAsync(
    "hotels-api",
    "rooms/available");

Dapr берёт на себя:
- service discovery;
- retries;
- трассировку запросов (tracing).
Никаких захардкоженных URL в коде.

2. Асинхронные события
Публикация события занимает одну строку:

await daprClient.PublishEventAsync(
    "pubsub",
    "booking-created",
    evt);

Подписчики обрабатывают события через атрибут [Topic].
Больше не нужен шаблонный код с BackgroundService.

3. Состояние приложения и кеширование
Хранилище типа key-value с подключаемыми backend'ами:

await daprClient.SaveStateAsync(
    "statestore",
    key,
    value);

Дополнительно:
↳ нужен TTL — передайте metadata;
↳ нужна оптимистичная блокировка — используйте ETag;
↳ backend может быть Redis, PostgreSQL или Cosmos DB.
4. Управление секретами
Больше не нужно хранить учётные данные в appsettings.

var secrets = await daprClient.GetSecretAsync(
    "secretstore",
    "payment-gateway");

В качестве backend можно использовать:
- Azure Key Vault;
- AWS Secrets Manager;
- HashiCorp Vault.
Код приложения остаётся одинаковым для всех окружений.

5. Распределённые блокировки
Взаимное исключение между экземплярами сервисов:

var lockResponse = await daprClient.Lock(
    "statestore",
    "room-101",
    "owner",
    30);

Например, это позволяет безопасно забронировать номер, даже если за него одновременно конкурируют три экземпляра сервиса.
Но главное преимущество Dapr — это то, что объединяет все эти возможности.
Каждое имя (pubsub, statestore, secretstore) привязано к YAML-компоненту.

Хотите заменить RabbitMQ на Kafka?
Достаточно изменить один YAML-файл.
Код приложения при этом остаётся без изменений.

👉 @KodBlog

Я до сих пор вижу эту ошибку в большинстве .NET API.

Эндпоинт принимает query-параметр, выполняет асинхронный запрос к БД и возвращает результат. На первый взгляд всё нормально. Но нигде нет CancellationToken.

Пользователь закрыл вкладку. Мобильный клиент словил таймаут. Load balancer разорвал соединение. А серверу всё равно. Он продолжает выполнять запрос, держит соединение, аллоцирует память и упорно считает результат, который уже никому не нужен.

Хотя .NET умеет это обрабатывать. Любой эндпоинт может принимать параметр CancellationToken, а фреймворк автоматически пробрасывает туда HttpContext.RequestAborted. Дальше просто передаёте токен в EF Core, HttpClient, file IO, channels — в любые async-вызовы. Как только запрос прерывается, операции останавливаются. SQL-запрос отменяется прямо во время выполнения. HTTP-вызов обрывается. Соединение возвращается в pool.
Два сценария, где это буквально разница между «система здорова» и «всё горит»:

Поток пользователей долбит медленный search-endpoint. Половина в ярости перекликивает UI и бросает запросы. Без токена сервер честно доводит каждый запрос до конца. С токеном брошенные запросы отменяются за миллисекунды, а pool остаётся доступен для тех, кто всё ещё ждёт ответ.

Долгий export падает на середине. Клиент делает retry уже с новыми параметрами. Без токена старый export продолжает молотить ещё две минуты, пока новый стоит в очереди за ним. С токеном разрыв соединения сразу освобождает worker.

Изменение — это всего два параметра: один в эндпоинте и один в методе доступа к данным. Всё.
Обычно в ответ слышу: «а что насчёт бэкграунд-задач, которые не должны отменяться?» Справедливо. Для них явно передавайте CancellationToken.None — и намерение сразу видно прямо в сигнатуре.
Каждый async IO-вызов в вашем коде должен принимать и прокидывать CancellationToken.

👉 @KodBlog