coollabsio/coolify · warning · Exception

Unknown log drain type.

Error message

Unknown log drain type.

What it means

The else of the first exhaustive if/elseif chain over $type in StartLogDrain. $type can only be one of 'none', 'newrelic', 'highlight', 'axiom', 'custom' — all set from settings flags at lines 17-27 — and every value has a branch, so this is an invariant assertion against future refactors (e.g. someone adds a new type detection without a config branch). Not reachable through the current settings-driven flow.

Source

Thrown at app/Actions/Server/StartLogDrain.php:137

    Host            api.axiom.co
    Port            443
    URI             /v1/datasets/\${AXIOM_DATASET_NAME}/ingest
    # Authorization Bearer should be an API token
    Header Authorization Bearer \${AXIOM_API_KEY}
    compress gzip
    format json
    json_date_key _time
    json_date_format iso8601
    tls On
");
            } elseif ($type === 'custom') {
                if (! $server->settings->is_logdrain_custom_enabled) {
                    throw new \Exception('Custom log drain is not enabled.');
                }
                $config = base64_encode($server->settings->logdrain_custom_config);
                $parsers = base64_encode($server->settings->logdrain_custom_config_parser);
            } else {
                throw new \Exception('Unknown log drain type.');
            }
            if ($type !== 'custom') {
                $parsers = base64_encode("
[PARSER]
    Name        empty_line_skipper
    Format      regex
    Regex       /^(?!\s*$).+/
");
            }
            $compose = base64_encode('
services:
  coolify-log-drain:
    image: cr.fluentbit.io/fluent/fluent-bit:2.0
    container_name: coolify-log-drain
    command: -c /fluent-bit.conf
    env_file:
      - .env
    volumes:

View on GitHub (pinned to 70b9acc424)

Solutions

  1. If you added a new drain type upstream in detection, add the corresponding config branch here and the env branch at line ~190.
  2. Otherwise treat as an internal bug: capture $type in logs and report the inconsistent state.
Defensive patterns

Strategy: try-catch

Validate before calling

$type = $server->isLogDrainEnabled() ? activeLogDrainType($server) : 'none';
in_array($type, ['none', 'newrelic', 'highlight', 'axiom', 'custom'], true)
    || throw new \InvalidArgumentException('Unsupported log drain type: '.$type);

Type guard

function isValidLogDrainType(string $type): bool
{
    return in_array($type, ['none', 'newrelic', 'highlight', 'axiom', 'custom'], true);
}

Try / catch

try {
    StartLogDrain::run($server);
} catch (\Exception $e) {
    if (str_contains($e->getMessage(), 'Unknown log drain type')) {
        // invariant violation / fork drift: log $type and report, do not retry
        report('StartLogDrain hit unknown type invariant: '.$e->getMessage());
    } else {
        throw $e;
    }
}

Prevention

When it happens

Trigger: Only via code change: extending the type detection to return a new provider without adding a matching config branch, or directly invoking handle() with tampered flow. No runtime input reaches it today.

Common situations: Maintainer refactors of the log-drain type detection; forks that add providers (e.g. Datadog) and forget the config chain.

Related errors


AI-assisted analysis of coollabsio/coolify@70b9acc424 (2026-08-17). Data as JSON: /api/errors/a8edc05ecfb77813. Report an issue: GitHub.