Skip to content

AirlockRunner swallows every exception, so airlock failures are invisible #136

Description

@GordonBeeming

AirlockRunner.cs has seven catch blocks with no exception variable, at lines 33, 229, 285, 314, 588, 707 and 757. Several of them return null and let the caller carry on:

catch
{
  return null;
}

GenerateRulesFile and GenerateComposeFile are the ones that matter most. If either throws, the caller sees null and airlock quietly doesn't start, or starts without the rules the user configured. Nothing is written to the console and nothing lands in a log, so from the outside it looks like airlock simply didn't apply. Working out why means reproducing it under a debugger, because the exception that would have explained it was discarded at the point it was raised.

This is the thing that turns a five-minute diagnosis into an afternoon. Every one of these paths should catch a typed exception where the failure is expected, name what failed and what got skipped as a result, and log at a level production keeps.

The wider point is that airlock has no positive signal on either side of its boundary. When rules don't reach the proxy there's nothing to compare, so the first sign of trouble is a user noticing traffic they expected to be blocked, or blocked traffic they expected to work.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions