-
Notifications
You must be signed in to change notification settings - Fork 1
Operations
Enabled plugins are booted during startup. Boot failures are intentional hard failures because they usually mean required configuration, gems, or infrastructure are missing.
Examples:
- enabling
rediswithout the optional Redis bundle group - enabling
postgreswithoutDATABASE_URL - enabling
admin_notificationswithoutADMIN_NOTIFICATION_CHANNEL_ID - enabling
harassmentwithoutpostgres
Runtime plugin hooks are isolated after boot. If a hook fails while handling messages or contributing optional behavior, the bot logs plugin_hook_failed and continues processing unrelated work.
The bot emits structured JSON logs by default. Each entry includes timestamp, level, event name, and event-specific fields.
Use plain logs locally:
LOG_FORMAT=plainEnable telemetry with:
PLUGINS=telemetry
TELEMETRY_ENABLED=true
OTEL_EXPORTER_OTLP_ENDPOINT=https://api.honeycomb.io
OTEL_EXPORTER_OTLP_HEADERS=x-honeycomb-team=secretkey
OTEL_SERVICE_NAME=OpenModBotInstall optional telemetry dependencies locally:
bundle config set --local with telemetry
bundle installFor Docker:
BUNDLE_WITH=telemetry docker compose buildWhen combining optional groups in Docker, use values such as BUNDLE_WITH=redis:postgres:telemetry.
The harassment background worker logs harassment_worker_failed when one processing pass fails, then continues polling due jobs. Repeated worker failures usually indicate an unhealthy classifier, repository, or database dependency and should be treated as operational alerts.
Historical Redis harassment state can be bootstrapped into Postgres:
PLUGINS=redis,postgres
ruby scripts/bootstrap_harassment_postgres.rbRebuild relationship-edge projections:
PLUGINS=postgres
ruby scripts/rebuild_harassment_relationship_edges.rbVerify Redis and Postgres counts before cutover:
PLUGINS=redis,postgres
ruby scripts/verify_harassment_postgres.rbThe full cutover sequence is documented in bot/docs/harassment-postgres-cutover.md.