feat(health): add support for TCP and none health check types

[AruneshDwivedi]

Summary

Fixes #666. Currently, health-check.sh only supports HTTP health checks via curl. Services using TCP protocols (like piper-audio with Wyoming) or CLI tools (like aider) either fail or are always shown as unhealthy.

Changes

Service Registry ()

• Added SERVICE_HEALTH_TYPES associative array
• Parse optional health_type field from manifest (default: http)
  • http: current behavior, HTTP GET via curl
  • tcp: check if port accepts TCP connections
  • none: skip health check (CLI tools)

Health Check (scripts/health-check.sh)

• Updated test_service() to handle all three health check types
• Added TCP health check using bash /dev/tcp/host/port
• Added none type to skip health check entirely
• Updated check_service() to skip CLI tools
• Updated display logic to show 'skipped' for none-type services

Usage

Add health_type to manifest.yaml:

service:
  id: piper-audio
  name: Piper Audio
  health_type: tcp     # TCP socket check
  # or
  health_type: none    # skip health check (CLI tools)

Testing

• tcp type uses bash built-in /dev/tcp for port checking (no external dependencies)
• none type sets result to 'skipped' and returns success
• Default http type maintains backward compatibility

Signed-off-by: Arunesh Dwivedi arunesh.devops@gmail.com

[Lightheartdevs]

Thanks for opening this. The direction is good, and http / tcp / none is the shape we want for this feature. I do not think we can merge this version yet, mostly because the new health type needs to become a repo-wide contract rather than a value only health-check.sh understands.

What we would need before this is mergeable:

1. Add health_type to the manifest contract

   Please add service.health_type to the service manifest schema(s), with an enum like:

   health_type: http | tcp | none

   Defaults should remain http for backward compatibility. Invalid values should fail validation instead of silently falling through to HTTP.

   Places to check/update:

   • dream-server/extensions/schema/service-manifest.v1.json
   • dream-server/extensions/library/schema/service-manifest.v1.json
   • dream-server/scripts/validate-manifest-schema.sh
   • any manifest docs / examples that describe health fields

2. Wire the field through the extension catalog / install path

   This PR currently parses health_type in service-registry.sh, but the services mentioned in Support non-HTTP health checks for TCP/CLI services #666 (piper-audio and aider) live in the extension library/catalog flow. The generated catalog currently carries health_endpoint and startup_check, but not health_type, so dashboard/API status still cannot reason about TCP vs CLI/no-health extensions.

   Please update the catalog generation and any installed-user-extension config loading that needs this value.

   Places to check/update:

   • dream-server/scripts/generate-extensions-catalog.py
   • dream-server/config/extensions-catalog.json after regeneration
   • dream-server/extensions/services/dashboard-api/config.py
   • dream-server/extensions/services/dashboard-api/user_extensions.py, if user-installed manifests should support the same field

3. Make all health surfaces agree

   Issue Support non-HTTP health checks for TCP/CLI services #666 is not just scripts/health-check.sh; the same health semantics should be visible in the dashboard/API and doctor/audit tooling. Today those paths are still HTTP-only or treat empty health as a special case.

   Please update the relevant surfaces so http, tcp, and none produce consistent statuses and messages:

   • dream-server/scripts/health-check.sh
   • dream-server/scripts/dream-doctor.sh
   • dream-server/scripts/audit-extensions.py
   • dream-server/extensions/services/dashboard-api/helpers.py
   • dream-server/extensions/services/dashboard-api/routers/extensions.py

4. Tighten the none behavior so it cannot hide broken services

   The current implementation returns success/skipped for health_type: none before checking whether a Docker container exists or is running. That can create false-green results if a real service is accidentally marked none.

   Please either:

   • restrict none to true CLI/no-runtime services, for example port: 0 plus startup_check: false, and validate that constraint; or
   • still check Docker/container state first for Docker services, then skip only the HTTP/TCP probe.

   The important rule is: none should mean “no network probe applies,” not “ignore whether this service is missing or stopped.”

5. Add actual fixtures/tests

   We need coverage for at least:

   • default behavior: missing health_type behaves as HTTP
   • health_type: http uses existing HTTP health behavior
   • health_type: tcp checks the configured port
   • health_type: none reports not-applicable/skipped without making a network probe
   • invalid values are rejected by validation
   • dashboard/API and doctor/audit behavior do not disagree with health-check.sh

6. Update the affected manifests

   To make this actually fix Support non-HTTP health checks for TCP/CLI services #666, please update the relevant library manifests rather than only adding the plumbing:

   • piper-audio should use TCP health against its Wyoming port
   • aider should use the CLI/no-health behavior, assuming it remains the intended one-shot CLI service

7. Keep TCP probes bounded by timeout

   HTTP checks use a timeout today. TCP checks should also honor the configured health timeout, or use another short bounded timeout, so a probe cannot hang longer than the health command expects.

Once those pieces are in place, this should be a good bounded PR: backward-compatible by default, explicit for TCP/CLI services, and consistent across CLI, doctor, dashboard, schema, and tests.

One smaller note: the PR body currently says Fixes #666. I would only use that once the schema/catalog/dashboard/doctor/test pieces above are included. Until then, something like Part of #666 or Adds initial health_type plumbing for #666 would be more accurate.

[AruneshDwivedi]

Thanks for the detailed review @Lightheartdevs. I understand the concerns — the current PR only adds plumbing in 2 files but the health_type needs to be a repo-wide contract. I'm working on implementing all 7 requirements:

1. ✅ Add health_type to manifest schema (enum: http|tcp|none, default http)
2. ✅ Wire through extension catalog / install path
3. ✅ Make all health surfaces agree (doctor, audit, dashboard)
4. ✅ Tighten 'none' behavior (check container state first, skip only network probe)
5. ✅ Add fixtures/tests
6. ✅ Update affected manifests (piper-audio → TCP, aider → none)
7. ✅ TCP probes bounded by timeout

I'll update the PR body to say "Part of #666" until all pieces are in place.

Working on this now — will push updates soon.