Skip to content

Identity on Spin, the same scope as T8 #1589

Description

@aram356

Summary

Identity on Spin, the same scope as T8; port the config block_on removal from RC commit 933de5921.

Part of #1558, server-side identity on every adapter. Plan ID T9, planned in wave 17 (after the MVP: Spin); priority P3, size L. Design: spec; order and dependencies: plan.

Requirements

ID-1 One EC lifecycle

On every supported adapter a consented document navigation or EC route call (ID-9) mints the EC, creates the record and sets ts-ec together. A cookie is never issued without a record. An existing EC is kept when geo is unknown.

ID-2 One shared record store

The identity logic stays in core and becomes awaitable (#1526). It runs on one EcKvStore over EdgeZero's KvStore (DEC-3). A store that cannot meet the contract makes startup reject identity configuration with a clear error.

ID-3 Partner APIs answered locally

Identify, batch sync, pull sync and admin lookup run on every adapter with a record store. Without one, identify and batch sync return a local error and never reach the publisher origin. Admin lookup already answers 501 locally; pull sync is outbound only.

ID-5 After-response work

Only pull sync and guarded follow-up writes run after the response is sent: after send on Fastly, a task drained on SIGTERM on Axum, waitUntil on Cloudflare. On Spin the work runs before the response (DEC-14; DEC-16 rules out skipping it).

ID-8 Body EIDs keep being saved

EIDs sent in the /auction body are saved to the record.

WB-1 Document and EC route responses only

Identity cookies are set on top-level HTML document responses and on EC route responses (ID-9), on every supported adapter.

SH-1 Built once

Settings, the partner registry, store clients and the HTTP client are built once per process or isolate.

SH-3 No executor nesting

No block_on runs inside async code.

SH-5 One app for every adapter

The identity routes (identify, batch sync, admin lookup and the EC route), pull sync, the EC lifecycle, provider lookups and cookie write-back run from one app built in core, which every adapter mounts and which builds its state once (SH-1). An adapter crate supplies only platform services: through EdgeZero where it offers them, and otherwise through the adapter's existing platform bridge until the EdgeZero ask lands (today Fastly's limiter, ID-6, and Fastly's geo, EZI-4). A capability an adapter lacks is an EdgeZero ask, never new code in that adapter (DEC-16).

Current state

What the code does today, from the design's survey at the revisions it names:

Acceptance criteria

  • ID-1: The conformance suite (T5) asserts on each supported adapter that a consented navigation creates the record and sets ts-ec in the same response, that a store failure sets no ts-ec, and that an existing EC survives unknown geo
  • ID-1: On an unsupported adapter, startup with identity configuration fails
  • ID-2: No adapter crate's non-test code implements EcKvStore, and a store reporting KvError::Unsupported for the contract fails startup with identity enabled
  • ID-3: In each adapter's tests a capturing origin receives no identify or batch-sync request
  • ID-3: With a store they run, without one they return 501
  • ID-5: On Fastly, Axum and Cloudflare a follow-up write recorded after send is in the record before the next navigation, and on Axum SIGTERM waits for it (A3). On Spin the follow-up write lands before the response
  • ID-8: On each supported adapter a body EID is in the record after the request
  • WB-1: Identity Set-Cookie headers appear on navigation and EC route responses and never on asset or other API responses
  • SH-1: An adapter test shows settings, the partner registry and store clients built once across two requests, and the HTTP client too, except Axum's, which stays per request until a measurement shows the Next.js regression gone
  • SH-1: After that measurement Axum's client is held to the same rule
  • SH-3: The remaining block_on calls are only at adapter entry points
  • SH-5: No adapter crate's non-test code calls EC generation, finalization or an identity handler directly, and the same conformance suite (T5) runs on each supported adapter

Dependencies

Blocked by:

Waits on these decisions:

  • DEC-8 Cloudflare and Spin store (open). Which store Cloudflare and Spin use by default for the record: the DynamoDB or celld adapter, or a native store that meets the contract, per Platform support. Blocks EZI-2c, EZI-2s, R3, T8 and T9.
  • DEC-14 Spin after-response work (open). The work runs before the response, because DEC-16 rules out skipping it. Open: the latency it may add and its bound. Blocks T9.

Blocks:

Notes from the plan

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