Skip to content

Sessions: add versioned, injectable persistence and define process ownership #1181

Description

@aranhave

Problem

SessionStore is a static store backed by several independent keys in UserDefaults.standard.

This creates three limits:

  • The stored shape has no schema version or explicit migration path.
  • Apps cannot inject a separate store, namespace, or App Group suite.
  • Ownership is undefined when multiple SessionManager instances, an app and its extensions, or multiple processes can write session state.

Adding fields as separate keys can also leave a mixed record if only part of an update is observed.

Proposed direction

Introduce an injectable persistence abstraction and store one versioned session record. Define the default ownership model and how an app may opt into sharing through an App Group or another store.

The exact storage protocol and encoding are open for discussion. The default should remain simple for a single app process, while shared storage should have documented coordination behavior rather than silently racing.

Ordering and scope

This follows the explicit linked-reset work in #1180 and #1183, because reset introduces a replacement-session persistence path that this storage contract must preserve.

This issue does not change what counts as session activity. Automatic telemetry continues to refresh inactivity by default. Session sampling is handled separately in #1182.

Acceptance criteria

  • Session persistence uses a versioned record that cannot mix fields from different writes.
  • Existing otel-session-* keys have a defined migration or fallback path.
  • Corrupt records and unknown schema versions fail safely without destroying data from a newer writer.
  • Callers can inject a persistence backend or UserDefaults suite and namespace.
  • Default behavior for the main app, extensions, and multiple managers is documented.
  • Opt-in shared storage defines how concurrent writers are coordinated or rejected.
  • Tests cover legacy data, corrupt and unknown records, isolated stores, concurrent managers, and shared-store interleaving.

Implementation is tracked in #1184.

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

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions