feat(native): route sprint tracks through the native IPC bridge - #411
Merged
Conversation
Closes plan 0015's "Android IPC — end-of-project follow-up". That section deferred the native side of sprint mode because it was gated on LapWing's release, and left `createNativeDeviceDetails()` reporting `supportsSprintTracks: false` with an empty sprint list — honest, but a dead end for anyone running the native app. LapWing now implements the TS* verbs behind its `logger_*_track` commands (a `TrackKind` plus a single opcode table in loggers/doveslogger/tracks.rs, mirroring trackOpcodes.ts here), so the bridge can reach /TRACKS/SPRINT. - ipc.ts: the four track commands take a `kind` and put it on the wire. It is optional on LapWing's side (defaulting to circuit, so a build of this app that predates sprint mode keeps working), but we always send it explicitly — it costs nothing and makes the IPC log legible. - dovesloggerConnection.ts: the seam forwards `kind` on all four verbs and flips `supportsSprintTracks` to true. Fixed in the seam, as 0015 required, rather than patched at a call site — this is still the one place the two transports are supposed to agree. - types.ts: the `listTracks` doc no longer points at the deferred follow-up. `supportsSprintTracks` stays in the interface: it is generic, and deviceSyncPlan/deviceSyncFetch still skip sprint entries for a transport that lacks the folder. Tests cover the kind reaching the wire on all four commands, and the seam forwarding it on get/put/delete — not just the listing. A sprint upload that silently landed in /TRACKS would be the worst failure here, so it is asserted directly. Gates: typecheck, lint, 2852 tests and the production build all pass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GdbzoPPBA6kaFfhTKgZEzg
|
This pull request has been ignored for the connected project Preview Branches by Supabase. |
Deploying with
|
| Status | Name | Latest Commit | Preview URL | Updated (UTC) |
|---|---|---|---|---|
| ✅ Deployment successful! View logs |
lapwing | daec0c9 | Commit Preview URL Branch Preview URL |
Aug 21 2026, 03:03 AM |
Coverage SummaryLines: 58.68% (7605/12958) · Statements: 57.82% · Functions: 55.96% · Branches: 55.7% Per-file coverage
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Closes plan 0015's "Android IPC — end-of-project follow-up".
That section deferred the native side of sprint mode because it was gated on LapWing's release, and left
createNativeDeviceDetails()reportingsupportsSprintTracks: falsewith an empty sprint list — honest, but a dead end for anyone on the native app. LapWing now implements theTS*verbs behind itslogger_*_trackcommands (aTrackKindplus a single opcode table inloggers/doveslogger/tracks.rs, mirroringtrackOpcodes.tshere), so the bridge can reach/TRACKS/SPRINT.ipc.ts— the four track commands take akindand put it on the wire. It's optional on LapWing's side (defaulting to circuit, so a build of this app predating sprint mode keeps working), but we always send it explicitly: it costs nothing and makes the IPC log legible.dovesloggerConnection.ts— the seam forwardskindon all four verbs and flipssupportsSprintTrackstotrue. Fixed in the seam, as 0015 required, rather than patched at a call site — this is still the one place the two transports are supposed to agree.types.ts— thelistTracksdoc no longer points at the deferred follow-up.supportsSprintTracksstays in the interface: it's generic, anddeviceSyncPlan/deviceSyncFetchstill skip sprint entries for a transport that lacks the folder.Tests cover the kind reaching the wire on all four commands, and the seam forwarding it on get/put/delete — not just the listing. A sprint upload that silently landed in
/TRACKSwould be the worst failure mode here, so it's asserted directly.Related Issues
Companion PR: TheAngryRaven/LapWing#33, which adds the
TS*verbs this depends on.Type of Change
Checklist
npm run lintpassesnpm run typecheckpassesnpm run test:runpasses — 2852 tests, 194 filesnpm run buildsucceedsREADME.md,CLAUDE.md, Credits,CHANGELOG.md) — plusdocs/plans/0015-sprint-mode.md, whose follow-up section this closesdatalogParser.ts, added tests, updated the formats table — n/aNotes for Reviewers
Merge ordering matters here. This PR makes the app send
kind: "sprint". A native shell without LapWing#33 would ignore the unknown argument and operate on the circuit folder instead — solistTracks("sprint")would return circuit tracks, and worse,putTrack(…, "sprint")would write a sprint course into/TRACKS. That's a silent wrong-folder write, not a clean failure.I checked before relying on it: LapWing has no releases and no tags — it has never shipped — so there is no native build in the wild that this can desync from, which matches 0015's own note that "the native app is not live yet". The two PRs just need to land before LapWing's first release, and shouldn't be split across it.
If you'd rather not depend on that ordering, the alternative is a capability probe or a version handshake over IPC before enabling sprint. I didn't build one, since the risk window is currently zero and it'd be real complexity for a case that can't happen yet — but it's the natural hedge if native release timing gets less certain.
One thing I deliberately did not change:
supportsSprintTracksis still on theDeviceDetailsinterface even though both shipped transports now returntrue.deviceSyncPlananddeviceSyncFetchgenuinely branch on it, and a future transport could lack the folder — removing it would be a bigger refactor than this PR warrants.Generated by Claude Code