Skip to content

Possible stale-api race after a source switch: album browser can send a link's ids to the new engine's server #74

Description

@kipp-ing

Found: 2026-09-14 by the adversarial review for #64 (T057). Not caused by #64, and not in the Home Assistant path. Unconfirmed: needs a red test first.

Suspected race

  • OwnFrame/OwnFrameApp.swift:805-811 (rebuildSlideshow) sets the new slideshow, then awaits makeAPI(), and only then bumps connectionGeneration.
  • For a link source makeAPI() re-resolves the link over the network (OwnFrameApp.swift:434-437), so the gap can be a real round trip.
  • During that gap SlideshowView keeps its old .id and holds the new engine with the old api.

Scenario (link → API-key album switch): the user opens Albums inside the gap (SlideshowView.swift:308-317). The browser lists the link's albums via the old api, and onSelect calls viewModel.switchAlbum(linkAlbumID) / jump(to: linkAssetID) on the new API-key engine, which would send the link's ids to the API-key server. handleConnectionChange(.albumMissing) (OwnFrameApp.swift:753) has the same stale-api pattern.

Uncertain because: the window is short and needs a manual tap, and whether jump(to:) fetches by id was not confirmed.

Todo

  • Red test that reproduces the stale engine/api pairing (or proves it can't happen).
  • If real: swap slideshow and api atomically (resolve makeAPI() before publishing the new engine, or bump the generation together).

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions