S13.05: BDD — Windows UDP delivery to syslog-ng

[DavidCozens]

Parent epic: #40

Goal

End-to-end BDD test verifying UDP syslog delivery from a Windows-built sender to syslog-ng.

Acceptance criteria

• BDD scenario: Windows UDP sender transmits a syslog message that syslog-ng receives and logs
• CI windows-build-and-test or a new BDD job validates the scenario
• Gherkin feature file documents the Windows UDP transport behaviour

Dependencies

• S13.04 (S13.04: WinsockResolver + WinsockDatagram — Windows UDP transport #128) — WinsockResolver + WinsockDatagram

Context

Validates the full Windows UDP transport chain end-to-end. Companion to S13.10 (#136) for TCP.

[DavidCozens]

Approach decided 2026-04-18 — Option C (single oracle, dual runner, no containers)

• Oracle: OpenTelemetry Collector Contrib as Windows-native BDD oracle (binds UDP 5514, protocol: rfc5424, JSONL file exporter). Runs as a plain Windows process on windows-2025 — no WSL, no Wine, no Docker.
• Runner: Python behave runs natively on the Windows runner and invokes the example .exe directly.
• SUT: New SolidSyslogWindowsExample.exe built via the existing msvc-debug preset; passed to the BDD job as an artefact.

Why not the alternatives

• ubuntu + docker --platform=windows/amd64 — QEMU can't host NT
• windows-latest — still maps to windows-2022 (no nested virt)
• windows-2025 + WSL2+docker-ce — works but ~90–120s warm-up + localhost-forwarding quirks
• Wine on ubuntu — Winsock UDP localhost/hostname/port-reuse quirks; fine as smoke test, not a conformance oracle

Scope fence

S13.5 adds Windows BDD only. Linux BDD stays on syslog-ng. Migrating Linux BDD to OTel Collector to unify oracles is a separate follow-up — keeps blast radius small.

BDD-first execution plan

1. Tag features by capability (`@udp` / `@tcp` / `@buffered`) and add `@windows_wip` to all UDP fire-and-forget features as a temporary rollout marker. (first PR — see below)
2. Build `SolidSyslogWindowsExample.exe` target gated on `SOLIDSYSLOG_WINSOCK AND HAVE_WINDOWS_PLATFORM`. Wires WinsockResolver+Datagram + WindowsClock/Hostname/ProcessId + WSAStartup/Cleanup. Reuse `Example/Common/` (fix `ExampleAppName` to handle `\ as well as \/`).
3. Install local Windows BDD tooling — `pip install behave` + pinned `otelcol-contrib` Windows zip — so the inner loop is local-first, not CI round-trips.
4. Make the walking-skeleton scenario green on Windows (`syslog.feature` first — remove its `@windows_wip`). Implementation needs emerge from the failing scenario.
5. Promote remaining `@windows_wip` features one at a time, fixing whatever Windows-specific issues each one surfaces.
6. CI job `bdd-windows` on pinned `windows-2025` (not `latest` — still maps to 2022) — packaging the now-known-good local recipe. Pin a specific `otelcol-contrib` version rather than tracking weekly cadence.

Threaded scenarios stay POSIX-only

Features that drive the long-running threaded example (interactive process protocol — `buffered`, `tcp_transport`, `tcp_reconnect`, `store_and_forward`, `store_capacity`, `power_cycle_replay`) are tagged `@buffered` and excluded from the Windows runner. Not a wip — a deliberate scope decision.

Rejected detour: `--batch N` CLI flag

Original plan included a `--batch N` flag on the example, assuming Windows `subprocess` couldn't drive the existing interactive stdin protocol. Reviewing `Bdd/features/steps/syslog_steps.py` shows the example is already used as fire-and-forget for every cross-platform scenario — adding `--batch N` would solve a problem we don't have, and would lose the prompt-return synchronisation primitive that prevents "BDD exits before validation" timing bugs. If Windows `subprocess` stdin turns out broken, we'll let the failing scenario drive the smallest fix.