demo.sh waits for Kafka, Postgres, MinIO, the Druid broker, the UI API, and the UI before declaring victory:
|
wait_for_container "osprey-kafka" 90 || exit 1 |
|
wait_for_container "postgres" 90 || exit 1 |
|
wait_for_container "minio" 90 || exit 1 |
|
|
|
# Wait for Druid broker (use HTTP check - no Docker health check configured) |
|
wait_for_http_service "Druid Broker" "http://localhost:8082/status" 180 || exit 1 |
|
|
|
# Wait for osprey services (HTTP check) |
|
wait_for_http_service "Osprey UI API" "http://localhost:5004/config" 120 || exit 1 |
|
wait_for_http_service "Osprey UI" "http://localhost:5002" 90 || exit 1 |
but it never checks osprey-worker—the one service that actually processes events. The worker is only mentioned up front, where the script checks that port 5001 is available:
|
check_port_available 5001 "Osprey Worker" || failed=1 |
So if the worker dies during startup (as it can: #432), the script still prints "Demo Ready!" and opens the browser on an empty UI, since nothing is consuming events.
Adding a wait_for_container "osprey-worker" alongside the other waits (or an HTTP check against the worker) before the ready banner would catch this.
demo.shwaits for Kafka, Postgres, MinIO, the Druid broker, the UI API, and the UI before declaring victory:osprey/demo.sh
Lines 260 to 269 in 958900a
but it never checks
osprey-worker—the one service that actually processes events. The worker is only mentioned up front, where the script checks that port 5001 is available:osprey/demo.sh
Line 121 in 958900a
So if the worker dies during startup (as it can: #432), the script still prints "Demo Ready!" and opens the browser on an empty UI, since nothing is consuming events.
Adding a
wait_for_container "osprey-worker"alongside the other waits (or an HTTP check against the worker) before the ready banner would catch this.