[compose] register minio storage backend on osprey-ui-api

[haileyok]

Summary

The example docker-compose.yaml set OSPREY_EXECUTION_RESULT_STORAGE_BACKEND (and the MinIO config it needs) on osprey-worker, but not on osprey-ui-api. The UI API process bootstraps its own storage backend, so its /scan endpoint was failing with AssertionError: No storage backend registered on a fresh setup. Add the same six env vars to the osprey-ui-api service so the example compose is usable out of the box.

Related Issues/Tasks

Closes #181

Changes Made

• Added to the osprey-ui-api service in docker-compose.yaml:
  • OSPREY_EXECUTION_RESULT_STORAGE_BACKEND=minio
  • OSPREY_MINIO_ENDPOINT=minio:9000
  • OSPREY_MINIO_ACCESS_KEY=minioadmin
  • OSPREY_MINIO_SECRET_KEY=minioadmin123
  • OSPREY_MINIO_SECURE=false
  • OSPREY_MINIO_EXECUTION_RESULTS_BUCKET=execution-output
• Values are byte-identical to the existing block on osprey-worker.

Confidence Level

Confidence Level: Claude

Testing

• docker compose config --quiet — passes (compose syntax valid).
• Env var names verified against bootstrap_execution_result_storage_service() in osprey_worker/src/osprey/worker/lib/storage/stored_execution_result.py and get_rules_execution_result_storage_backend() in osprey_worker/src/osprey/worker/_stdlibplugin/execution_result_store_chooser.py.
• Not booted end-to-end in this session because of a parallel-worktree compose conflict; the failure mode (Missing storage backend in example Docker Compose file #181's traceback) is deterministic on the missing env var, so the fix is straightforward to verify on the next clean ./start.sh.

Follow-up note (out of scope here)

osprey-ui-api.depends_on does not gate on minio: service_healthy like osprey-worker.depends_on does — the transitive chain via osprey-worker covers the typical boot order but leaves a narrow race. Worth a separate compose-hardening pass; deliberately not included here per the "minimal and scoped" rule.

Summary by CodeRabbit

• Chores
  • Updated execution result storage configuration in the deployment setup to use MinIO-backed storage with the associated endpoint and authentication credentials.

[coderabbitai]

📝 Walkthrough

Walkthrough

The docker-compose.yaml file is updated to configure the osprey-ui-api service with MinIO-backed execution result storage. Six environment variables are added to specify the MinIO storage backend, endpoint, credentials, secure flag, and results bucket.

Changes

MinIO Configuration

Layer / File(s)	Summary
osprey-ui-api MinIO environment configuration docker-compose.yaml	osprey-ui-api service environment now includes OSPREY_EXECUTION_RESULT_STORAGE_BACKEND=minio and MinIO connection parameters: endpoint, access key, secret key, secure flag, and execution-output bucket.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly summarizes the main change: registering MinIO storage backend on osprey-ui-api in the docker-compose configuration.
Linked Issues check	✅ Passed	The pull request fully addresses issue #181 by adding all required MinIO environment variables to osprey-ui-api, enabling proper storage backend initialization and fixing the /scan endpoint and event stream.
Out of Scope Changes check	✅ Passed	All changes are directly related to resolving the linked issue; only the necessary MinIO environment variables were added to osprey-ui-api in docker-compose.yaml.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch claude/bug-181-storage-backend

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

docker-compose.yaml (1)

140-144: ⚠️ Potential issue | 🟠 Major | ⚖️ Poor tradeoff

Add MinIO service dependencies to prevent startup race.

The osprey-ui-api service now depends on MinIO storage (lines 163-168) but does not gate startup on MinIO readiness. This can cause bootstrap failures if osprey-ui-api starts before MinIO is healthy or the bucket is initialized.

Consider adding the same MinIO dependencies that osprey-worker has (lines 97-100):

depends_on:
  - osprey-worker
  - druid-broker
  - postgres
  - snowflake-id-worker
  minio:
    condition: service_healthy
  minio-bucket-init:
    condition: service_completed_successfully

I acknowledge your follow-up note about deferring this to a separate compose-hardening PR, but flagging for visibility since it can cause intermittent failures on fresh setups.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docker-compose.yaml` around lines 140 - 144, The osprey-ui-api service's
depends_on block is missing MinIO readiness gating which can cause startup
races; update the osprey-ui-api service depends_on (the block that currently
lists osprey-worker, druid-broker, postgres, snowflake-id-worker) to also
include minio with condition: service_healthy and minio-bucket-init with
condition: service_completed_successfully so osprey-ui-api waits for MinIO to be
healthy and the bucket-init task to finish before starting.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@docker-compose.yaml`:
- Around line 163-168: The change modifies restricted deployment settings in
docker-compose.yaml by altering environment variables like
OSPREY_EXECUTION_RESULT_STORAGE_BACKEND, OSPREY_MINIO_ENDPOINT,
OSPREY_MINIO_ACCESS_KEY, OSPREY_MINIO_SECRET_KEY, OSPREY_MINIO_SECURE and
OSPREY_MINIO_EXECUTION_RESULTS_BUCKET; do not merge this change until you obtain
explicit human approval from the ops/security owner—revert or hold the patch and
add a PR comment requesting approval, include justification for changing those
OSPREY_* variables, and document any required review approvals before reapplying
the updated docker-compose.yaml.

---

Outside diff comments:
In `@docker-compose.yaml`:
- Around line 140-144: The osprey-ui-api service's depends_on block is missing
MinIO readiness gating which can cause startup races; update the osprey-ui-api
service depends_on (the block that currently lists osprey-worker, druid-broker,
postgres, snowflake-id-worker) to also include minio with condition:
service_healthy and minio-bucket-init with condition:
service_completed_successfully so osprey-ui-api waits for MinIO to be healthy
and the bucket-init task to finish before starting.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 9392b7aa-d415-4c77-b67e-1aaa6e6b5e9f

📥 Commits

Reviewing files that changed from the base of the PR and between 615ac01 and 0341415.

📒 Files selected for processing (1)

• docker-compose.yaml

[haileyok]

Hailey: validated locally that this fixes things the way claude describes