а для чего нужно

для произвольных типов данных

типа
Pipe A B

nom в расте умеет с любыми инпутами

да

эх

сделой такую

ок

Глупый вопрос: есть приложение, оно запускается в Resource[F, A]. У приложения есть состояние. Есть идея в том чтобы на graceful shutdown приложения это состояние записывать в базу данных.

У меня есть ощущение что записывать это состояние при cancel ресурса - это плохая идея. Но аргументов мало. Из того что приходит в голову: (1) тот кто создаёт Resource может не ожидать что его закрытие будет относительно долгим, (2) cancel ресурса - это конкурентная операция, со всеми выходящими последствиями, (3) надо использовать Resource.makeCase или вроде того чтобы не попасть на двойную ошибку (если ошибка случилась и в use и в самой записи в базу данных).

Уговорите (или отговорите) всё-таки (не)сливать состояние в базу на cancel ресурса.

можно просто вспомнить, что этот аргумент называется "cleanup", а не cancel

и ощущения меняются сразу

Хочется добавить что конкретный юз кейс это стейтфул обработка сообщений из кафки с сохранением промежуточного состояния и коммитом оффсетов :)

1. "Тот, кто создаёт Resource может не ожидать, что закрытие будет долгим" - для описания того, что можно ожидать от процесса есть tagless final, или Reader capabilities

Т.е. у вас exactly once ?

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

Нет, at least once

Тогда почему нельзя коммитить только удачно обработанные офсеты, а если упадет - поднять и перечитать ?

Если долго релизим ресурс то нас кафка брокер и так выкинет через конфигурируемое время из группы (дефолт 5 минут вроде), можно сделать таймаут же в релизе ресурса?

да что-угодно можно делать в релизе ресурса

можно бесконечный процесс сделать