Fix Linux build of AlibabaTokenPlanCookieHeader#1105
Conversation
…eHeader AlibabaTokenPlanCookieHeader.swift uses HTTPCookie (lines 79, 94, 95, 97-99, 102, 113, 118, 134, 146) but only imports Foundation. On macOS HTTPCookie lives in Foundation, but on Linux it was moved to FoundationNetworking and is "explicitly marked unavailable" in Foundation — so the new file added in steipete#1098 (Alibaba Token Plan provider) breaks the Linux build of CodexBarCore outright. Sibling new files in the same PR (AlibabaTokenPlanUsageFetcher, T3ChatUsageFetcher) already use the right conditional import; this one was overlooked. Verify on Ubuntu 24.04 x86_64 with Swift 6.2.4: Before: `swift build` -> `error: 'HTTPCookie' is unavailable: This type has moved to the FoundationNetworking module. Import that module to use it.` (10+ occurrences across the file, build aborts) After: `swift build` -> Build complete! (72.86s) `swift test` -> 14/14 pass (3 suites) No source-of-truth change beyond restoring buildability — adds the same `#if canImport(FoundationNetworking) / import FoundationNetworking / #endif` block that already guards GeminiStatusProbe, ManusCookieHeader, AlibabaTokenPlanUsageFetcher, T3ChatUsageFetcher, etc. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
|
Codex review: needs maintainer review before merge. Latest ClawSweeper review: 2026-05-22 11:31 UTC / May 22, 2026, 7:31 AM ET. Workflow note: Future ClawSweeper reviews update this same comment in place. How this review workflow works
Summary Reproducibility: yes. Source inspection shows current main uses PR rating What the crustacean ranks mean
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics. Real behavior proof Next step before merge Security Review detailsBest possible solution: Merge the conditional import after normal CI/maintainer checks, preserving the existing Alibaba Token Plan behavior. Do we have a high-confidence way to reproduce the issue? Yes. Source inspection shows current main uses Is this the best way to solve the issue? Yes. The PR applies the narrow existing cross-platform import pattern without changing provider behavior or cookie handling. Label changes:
Label justifications:
What I checked:
Likely related people:
Codex review notes: model gpt-5.5, reasoning high; reviewed against 68a6b23ba641. |
|
ClawSweeper PR egg ✨ Hatched: 🥚 common Moonlit Branchling Hatch commandComment Hatchability rules:
Rarity: 🥚 common. What is this egg doing here?
|
|
Thanks for catching this. The exact Linux build fix is already on Proof: the post-merge #1104 checks were green for Linux x64, Linux arm64, and Closing this one as superseded so the queue stays tidy. Appreciate the tight repro and verification. |
AlibabaTokenPlanCookieHeader.swift uses HTTPCookie (lines 79, 94, 95, 97-99, 102, 113, 118, 134, 146) but only imports Foundation. On macOS HTTPCookie lives in Foundation, but on Linux it was moved to FoundationNetworking and is "explicitly marked unavailable" in Foundation -- so the new file added in #1098 (Alibaba Token Plan provider) breaks the Linux build of CodexBarCore outright. Sibling new files in the same PR (AlibabaTokenPlanUsageFetcher, T3ChatUsageFetcher) already use the right conditional import; this one was overlooked.
VERIFICATION
Ubuntu 24.04 x86_64 with Swift 6.2.4:
Before:
$ swift build
error: 'HTTPCookie' is unavailable: This type has moved to the
FoundationNetworking module. Import that module to use it.
(10+ occurrences across the file, build aborts)
After:
$ swift build
Build complete! (72.86s)
$ swift test
Test run with 14 tests in 3 suites passed
No source-of-truth change beyond restoring buildability -- adds the same
"#if canImport(FoundationNetworking) / import FoundationNetworking / #endif"
block that already guards GeminiStatusProbe, ManusCookieHeader,
AlibabaTokenPlanUsageFetcher, T3ChatUsageFetcher, and others.