# Per-recipe harness config for mumble (Phase 2 Q4.2 — a TCP/voice recipe, not HTTP-native).
#
# Mumble's voice server speaks its own TLS protocol on 64738 (no HTTP API). To fit cc-ci's
# HTTP-readiness + on-host test model we deploy upstream recipe overlays:
#   - compose.mumbleweb.yml  -> a mumble-web HTTP client routed through Traefik on the app domain,
#     giving the generic harness a real HTTP readiness/serving signal (HEALTH_PATH "/") AND the
#     web_client.py parity surface. Shipped upstream from 0.1.0 (present on the 0.2.0 base too).
#   - compose.host-ports.yml -> publishes 64738 (tcp+udp, mode:host) on the cc-ci host so on-host
#     tests (cc-ci-run) reach the voice server at 127.0.0.1:64738. Shipped upstream ONLY from 1.0.0.
#
# F2-14c disposition (Adversary REVIEW-2 @16:22:07Z VETO): the upgrade tier's base is the previous
# published version 0.2.0+v1.6.870-0, which PREDATES compose.host-ports.yml (added in 1.0.0). We do
# NOT carry a cc-ci copy of that upstream overlay (no fork). Instead:
#   - the BASE 0.2.0 deploys MINIMALLY with `compose.yml:compose.mumbleweb.yml` (HTTP health via
#     mumble-web works; the voice port is NOT host-published on 0.2.0), and the on-host voice/protocol
#     custom tests are SKIPPED on 0.2.0 (they run in the CUSTOM tier, which executes once on the
#     post-upgrade LATEST);
#   - the UPGRADE to latest (1.0.0+, which ships compose.host-ports.yml NATIVELY) adds host-ports to
#     COMPOSE_FILE via UPGRADE_EXTRA_ENV (applied by generic.perform_upgrade after the PR-head
#     checkout, before the chaos redeploy), so the voice port IS host-published on latest and the
#     voice tests run there. The current version's native overlay is untouched (no cc-ci fork).
#
# Distinctive config markers (read back by the recipe-specific functional tests, proving our config
# actually propagated into the running server — version-independent, not hard-coded upstream values):
#   WELCOME_TEXT -> MUMBLE_CONFIG_WELCOMETEXT, surfaced in the ServerSync welcome_text.
#   USERS        -> MUMBLE_CONFIG_USERS (max users), surfaced in the ServerConfig.max_users.

HEALTH_PATH = "/"  # mumble-web client UI (present on both 0.2.0 base and 1.0.0 latest)
HEALTH_OK = (200,)

DEPLOY_TIMEOUT = 900  # two images to pull (mumble-server + mumble-web) on a cold node
HTTP_TIMEOUT = 300

# A unique, stable welcome-text marker the round-trip test asserts surfaces over the protocol
# (underscore prefix = recipe-private constant, exempt from registry validation — rcust P1).
_WELCOME_TEXT_MARKER = "cc-ci-mumble-welcome-7f3a9c"
# A distinctive max-users value (not the recipe default 100) the server_config test asserts.
_MAX_USERS = 42

# BASE deploy (0.2.0): mumble-web only — NO host-ports (0.2.0 predates it). The voice-config env is
# set here and persists across the upgrade so it takes effect on the latest (where the custom config
# round-trip tests assert it).
EXTRA_ENV = {
    "COMPOSE_FILE": "compose.yml:compose.mumbleweb.yml",
    "WELCOME_TEXT": _WELCOME_TEXT_MARKER,
    "USERS": str(_MAX_USERS),
}

# UPGRADE-target deploy (latest 1.0.0+): add the NATIVE compose.host-ports.yml so 64738 is
# host-published and the on-host voice/protocol custom tests can run on latest.
UPGRADE_EXTRA_ENV = {
    "COMPOSE_FILE": "compose.yml:compose.mumbleweb.yml:compose.host-ports.yml",
}


def READY_PROBE(ctx):
    # The voice server on 64738 is testable on-host ONLY when compose.host-ports.yml is active — i.e.
    # the post-upgrade LATEST, not the minimal 0.2.0 base. Read the live COMPOSE_FILE to decide, so the
    # SAME probe fn is correct in both phases: the post-install probe (base, no host-ports) returns []
    # (HTTP health alone gates the base), the post-upgrade probe (latest, host-ports) gates readiness
    # on the voice port being STABLY listening (3 consecutive connects) before the harness proceeds to
    # backup — after the chaos upgrade redeploy the host-mode 64738 must be released by the old task and
    # rebound by the new one (a window where mumble-web 200s while the voice container isn't yet up, and
    # backup-bot would then exec into a not-running app container -> 409).
    from harness import abra  # lazy: recipe_meta is exec'd with `harness` importable at call time

    cf = abra.env_get(ctx.domain, "COMPOSE_FILE") or ""
    if "compose.host-ports.yml" in cf:
        return [{"tcp_host": "127.0.0.1", "tcp_port": 64738, "stable": 3}]
    return []


# canon §2.B: enroll as a DATA-WARM canonical (all recipes enrolled — operator 2026-06-17).
# The weekly sweep promotes this recipe's canonical to its latest green RELEASE TAG.
WARM_CANONICAL = True
