@iworkflow/dbos

DBOS для @iworkflow/core. Peer: @dbos-inc/dbos-sdk ^5.3; зависимость pg.

• dbosRuntime({ systemDatabaseUrl }).start(def) — приложение def.app, очередь def.app, версия <app>-patching.

• dbosClient() — старт, сигнал, query по id.

• Модули, зовущие друг друга, делят одну системную базу: dbosRuntime({ systemDatabaseUrl }) / dbosClient({ systemDatabaseUrl }) или DBOS_SYSTEM_DATABASE_URL; без адреса — отказ. Тесты модуля — в своей базе: одноимённые очереди перехватывают задачи.

• Своё в схеме iwf: heartbeat (прогресс шага), birth (патчи кода, начавшего процесс).

• Запуск модулей — под advisory-замком: миграции DBOS на пустой базе иначе ловят deadlock.

• Рантайм владеет DBOS процесса: stop снимает все регистрации DBOS, повторный start регистрирует заново.

• Прод — роль на модуль: схему ведёт владелец базы, модуль без DDL — DBOS_ADMIN_URL=<владелец> bunx -p @iworkflow/dbos iworkflow-dbos migrate --prune --app italent=italentproduction ... (полный список модулей; без --prune роли только добавляются; повторять после обновления пакета), у модуля dbosRuntime({ systemDatabaseUrl, migrate: false, connection: { password: () => token() } }) — вход токеном, остальное из адреса (sslmode, sslrootcert). Триггеры: роль модуля пишет только свои процессы, чужому — завести в очередь, отменить, послать сообщение; дочерний — только от модуля родителя, так что parentId, вход и итог чужого процесса записью в базу не подделать. Роль вне списка — отказ. Версия DBOS_APPLICATION_VERSION — с префиксом <модуль>-.

• Системной базы нет — start создаёт её (нужен доступ к базе postgres и право CREATEDB), иначе заведи заранее.

• Все поды с executor id local: новый под восстанавливает PENDING-процессы, пока старый ещё их ведёт. В k8s — один под и strategy: Recreate, пока нет своего executor id на под.

Переменные: DBOS_SYSTEM_DATABASE_URL, DBOS_QUEUE_POLL_MS, DBOS_RESULT_POLL_MS, DBOS_APPLICATION_VERSION.