Flake: Swift conformance run-timeout-raises-and-keeps-partial-text loses the partial text on a slow runner

[jhgaylor]

What failed

Swift SDK (ubuntu-24.04) / swift test --filter ConformanceTests, scenario run-timeout-raises-and-keeps-partial-text, on PR #1722 (no Swift or conformance changes in the PR; the only SDK-facing change is one optional query parameter in the contract).

↳ conformance FAILED for swift-kit / run-timeout-raises-and-keeps-partial-text
    A run that outlives its timeout raises, and the error carries what the agent said so far
    error
        expected {
          "kind" : "timeout",
          "partial_text" : "Half an answer"
        }
        got {
          "code" : null,
          "field_errors" : { },
          "kind" : "timeout",
          "partial_text" : "",
          "retry_after" : null,
          "retryable" : false,
          "status" : null
        }

First attempt: https://github.com/BinaryBourbon/fountain/actions/runs/34085084699/job/101627491478 (2026-09-07 05:00Z). Rerun of the same commit with no code change: passed. The ubuntu job passed on the eight preceding PR runs the same morning, and on main at 2a0f16c (02:23Z).

How often

One failure in nine ubuntu runs on 2026-09-07 (first attempt of PR #1722), passing on rerun.

Mechanism (probable)

The scenario scripts a stream that sends "Half an answer" and then goes quiet, with a 300 ms client timeout. The kind was timeout and the partial text was empty, so the timeout fired before the first chunk had been read: the assertion is on the text having arrived, but the only thing it waits on is the 300 ms clock. On a slow runner the fake server's first frame can lose that race. The other three SDKs did not fail on the same run. #1424 (closed 09-03) was a different divergence in the same scenario (an extra GET after the timeout), not this.

A fix would either have the scenario wait for the first chunk to be observed before starting the timeout clock, or give the timeout more headroom relative to the scripted delay.

[jhgaylor]

Second occurrence, 2026-09-10 — merged from #1861

Filed separately as #1861 during a week when this issue was not found by search; closing that one as a duplicate and moving its evidence here so the two occurrences sit together, per the "a second issue splits the evidence" rule in CLAUDE.md.

Same job (Swift SDK (ubuntu-24.04)), same scenario, same assertion: the error kind is right and only partial_text is empty.

---

swift test --filter ConformanceTests on Swift SDK (ubuntu-24.04) fails the shared conformance scenario run-timeout-raises-and-keeps-partial-text.

The assertion

↳ conformance FAILED for swift-kit / run-timeout-raises-and-keeps-partial-text
    A run that outlives its timeout raises, and the error carries what the agent said so far
        expected { "kind": "timeout", "partial_text": "Half an answer" }
        got      { "kind": "timeout", "partial_text": "", ... }

sdk/swift/Tests/.../ConformanceTests.swift:34:19. The error kind is right; only the accumulated partial text is missing.

How often, out of what

One in four, in the same minute, on trees that contain each other. Four PRs of the #1634 stack ran the identical Swift sources (the stack touches no Swift file at all) within about three minutes of each other on 2026-09-10:

PR	Swift SDK (ubuntu-24.04)	run
#1836	fail	https://github.com/managoat/fountain/actions/runs/34480161111/job/102880722710
#1837	pass	—
#1838	pass	—
#1839	pass	—

#1837, #1838 and #1839 are stacked on #1836, so each one's tree is a strict superset of the failing one. git diff --name-only origin/main stack/1634-8-docs matches nothing under sdk/swift.

Mechanism

The scenario writes some SSE text, then lets the run exceed its timeout, and asserts the raised error carries the text seen so far. The client asserts on text it accumulated from the stream but waits on the timeout, and the two are not ordered with respect to each other: on a loaded runner the timeout deadline can fire before the first frame is read off the socket, and the error is then raised with an empty buffer. The kind being correct while only `partial_text" is empty is what points at ordering rather than at the timeout logic.

So the fix is likely in the Swift client's timeout path (drain what has already arrived before raising), or in the scenario (make the first frame observable before the deadline can win), rather than in the deadline itself.

The other three SDKs run the same scenario from sdk/conformance/scenarios and did not fail here; whether they are ordered correctly or merely luckier is worth checking as part of the fix.