Skip to content

tests: fix String→TabID mismatch in WorkspaceLayoutExecutorAcceptanceTests - #115

Merged
BenevolentFutures merged 1 commit into
mainfrom
test-tabid-string-mismatch
May 4, 2026
Merged

BenevolentFutures merged 1 commit into
mainfrom
test-tabid-string-mismatch

Conversation

@BenevolentFutures

Copy link
Copy Markdown
Contributor

Summary

Unblocks `mailbox-unit` (`mailbox-parity.yml`) on every PR/push that triggers it. The compile error was already there but masked by SentryHelper.swift's MetricKit issue; #114 cleared that and this surfaced as the next layer.

What's broken on `origin/main`

```
c11Tests/WorkspaceLayoutExecutorAcceptanceTests.swift:480:68: error:
cannot convert value of type 'String' to expected argument type 'TabID'
c11Tests/WorkspaceLayoutExecutorAcceptanceTests.swift:500:13: error:
conflicting arguments to generic parameter 'T' ('String?' vs. 'TabID')
```

`ExternalTab.id` is a stringified UUID (bonsplit's external view) but `Workspace.panelIdFromSurfaceId(:)` and `surfaceIdFromPanelId(:)` are typed on the opaque `TabID` wrapper. The `comparePane` helper:

  • passes `tab.id` (String) where `TabID` is expected, and
  • compares `livePane.selectedTabId` (String?) against `expectedTabId` (TabID) inside `XCTAssertEqual`.

Fix

Apply the same conversion `WorkspacePlanCapture.panelID(forTabIDString:)` uses at the v2 socket boundary: parse the UUID string and wrap with `TabID(uuid:)`. For the equality assertion, project the TabID wrapper to its canonical UUID-string form so both sides of `XCTAssertEqual` are in the same value space.

Why this didn't catch locally before

Two reasons: (1) `xcodebuild build` on the `c11-unit` scheme only builds the host app target — `build-for-testing` (or `test`) is what compiles the test target; (2) Local Xcode 26 / Swift 6.2 happens to accept the old code through some inference path that Xcode 16.4 / Swift 6.1 in CI does not. The fix compiles cleanly on both.

Why no one else has hit this

`mailbox-parity.yml` only triggers when `Sources/Mailbox/**`, `CLI/c11.swift`, etc. change. Most main pushes don't touch those paths so the workflow doesn't run, so this regression has been quietly sitting on main since the TabID wrapper was introduced.

Test plan

  • Local build clean (the file now compiles without error on Swift 6.2)
  • CI `mailbox-unit` job goes green for the first time since the breakage

🤖 Generated with Claude Code

…tanceTests

`ExternalTab.id` is a stringified UUID (bonsplit's external view), but
`Workspace.panelIdFromSurfaceId(_:)` and `surfaceIdFromPanelId(_:)` are
typed on the opaque `TabID` wrapper. The `comparePane` helper passes
`tab.id` (String) where TabID is expected and compares `livePane.selectedTabId`
(String?) against `expectedTabId` (TabID), which fails to compile on
Xcode 16.4 / Swift 6.1 in CI:

    c11Tests/WorkspaceLayoutExecutorAcceptanceTests.swift:480:68: error:
        cannot convert value of type 'String' to expected argument type 'TabID'
    c11Tests/WorkspaceLayoutExecutorAcceptanceTests.swift:500:13: error:
        conflicting arguments to generic parameter 'T' ('String?' vs. 'TabID')

The error has been there since the TabID wrapper was introduced; it was
masked by the SentryHelper.swift compile error fixed in #114, which
short-circuited the test build before this batch ran. Once #114 cleared
that, this surfaces.

Apply the same conversion `WorkspacePlanCapture.panelID(forTabIDString:)`
uses at the v2 socket boundary: parse the UUID string and wrap with
`TabID(uuid:)`. For the equality assertion, project the TabID wrapper to
its canonical UUID-string form so both sides of `XCTAssertEqual` are in
the same value space.

Local Xcode 26 / Swift 6.2 happens to accept the old code through some
inference path; CI does not. The fix compiles cleanly on both.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
@BenevolentFutures
BenevolentFutures merged commit e164a71 into main May 4, 2026
5 of 6 checks passed
@BenevolentFutures BenevolentFutures mentioned this pull request May 5, 2026
3 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant