experimental-a2 0.21.1 → 0.23.0

package/docs/reference/04-ai.mdx

@@ -131,8 +131,8 @@ Pure typed builders of `ai.control.requested` commands, for `append()` and
   event ID, and must. Approval, input-response, and retry builders use stable
   interaction IDs; other commands use the ID `push()` or `append()` assigns,
   kept across transport retries. Caller IDs are nonempty, never start with the
-  reserved `a2.ai:`, and are unique across the store; identical events replay
-  and conflicting reuse rejects before append. A2's own IDs are opaque,
+  reserved `a2.ai:`, and are unique within the session; identical events
+  replay and conflicting reuse in the session rejects before append. A2's own IDs are opaque,
   fixed-length, deterministic `a2.ai:` values; an assistant message's ID is its
   initial model-request event's ID.
 - **Passive input.** `generate: false` is valid browser input: it admits the
@@ -539,7 +539,9 @@ their `https:` or `data:` URLs; any other file fails the turn. See
 
 A harness resumes after a crash at the interrupted step. Finished model calls
 are not made again and finished tool calls do not run again. A2 rebuilds the
-harness for each step from the log, and stores nothing outside it. Each agent
+harness for each step from the log, unless [`fx()`](#fx) continues the kernel
+its previous step left in the same process, and keeps nothing durable outside
+the log. Each agent
 keeps, in its process's memory, the harness's state at the end of the last
 response it ran there, FX's checkpoint or Pi's session, so a warm process reads
 and replays only the log since; a cold one reads and replays the session from
@@ -600,7 +602,14 @@ response so far from the log: recorded model responses and tool results answer
 the kernel without network calls or tool runs, then FX makes its next model
 call. Replay grows with the response, roughly 0.1 to 0.5 seconds for one of 80
 to 200 tool calls. When libfx can't take a checkpoint, A2 replays from an
-earlier one.
+earlier one. The process that ran the step before skips the replay: it keeps
+FX's kernel waiting on that step's tool calls, and the next step gives the
+kernel any steering sent meanwhile, answers its tool calls from the log, and
+lets it go on. A step that finds anything else first, such as changed model
+settings or a model call another process committed, closes that kernel and
+replays. A kept kernel holds its process open, so A2 closes it once the session
+has nothing left to run in that process: however a response ends, its process
+can exit.
 
 FX's model calls carry the same [AI Gateway](#agentoptions) defaults as the
 AI SDK harness: `caching: 'auto'`, under any Gateway options FX sets itself,

package/docs/reference/06-errors.mdx

@@ -39,7 +39,7 @@ export async function POST(req: Request) {
 | `UNKNOWN_EVENT_TYPE` | an event type isn't in the contract's `events` map | no |
 | `UNKNOWN_PRESENCE_FIELD` | a presence field isn't in the contract's `presence` map | no |
 | `PRESENCE_NOT_SUPPORTED` | the contract declares `presence` but the store has no presence capability. Thrown at construction; for environment-resolved stores, at first store use | no |
-| `PARTIAL_DUPLICATE_BATCH` | a batch mixes already-appended and fresh events, contains the same id twice, or uses an id already used in a different session (event ids are globally unique). Always a caller bug; nothing was written | no |
+| `PARTIAL_DUPLICATE_BATCH` | a batch mixes already-appended and fresh events, or contains the same id twice. Event ids are unique per session, so an id used in another session never conflicts. Always a caller bug; nothing was written | no |
 | `SUPERSEDED_ATTEMPT` | a consumer's append or clear comes from an attempt that a recovery claim or a session clear replaced; nothing was written. Also the abort reason on that attempt's `ctx.signal` | no |
 | `SESSION_CLEARED` | a state read reaches below the latest clear, a consumer reads state past a clear of its event, or an actor call is cleared before it receives its answer | no |
 | `CLAIM_EXPIRED` | never thrown; only the `ctx.signal` abort reason when the attempt's lease lapsed without renewal (assumed loss, decided locally, not proof) | no |

package/docs/server/01-consumers.mdx

@@ -367,7 +367,10 @@ Consumers are at-least-once. A crash after your side effect but before A2
 records completion runs the event again.
 
 - **External side effects take an idempotency key.** `event.id` is stable
-  across attempts.
+  across attempts and unique within its session. Ids your callers pick, and
+  the ids A2 derives from them, can repeat in another session: when yours can,
+  add the session to the key, and the contract's name if several contracts
+  share it, as in `` `orders:${event.sessionId}:${event.id}` ``.
 - **Named appends are deduplicated.** A retry gets the existing events back.
 - **Returned events commit with completion.** They all exist with the
   cursor's advance, or none do.

package/docs/server/06-guarantees.mdx

@@ -5,8 +5,9 @@ description: Appends are effectively-once, consumers are at-least-once, and retr
 
 ## In short
 
-- **Appends are effectively-once.** Event ids deduplicate writes. A batch commits
-  before its consumers start; they may start before `append` resolves.
+- **Appends are effectively-once.** Event ids deduplicate writes within a
+  session. A batch commits before its consumers start; they may start before
+  `append` resolves.
 - **Consumers are at-least-once.** They may run again after a crash, so
   [side effects use idempotency keys](/server/consumers#consumers-can-run-twice).
 - **The log stays ordered.** Every session has one immutable append order.
@@ -50,8 +51,10 @@ the committed rows back. A partial or changed batch is rejected.
 
 The transaction covers only A2's log. An HTTP call, database write, or other
 external effect can't join it, so a crash after the effect but before
-completion repeats it. Use `event.id` as an idempotency key or add fencing in
-the external system.
+completion repeats it. Use `event.id` as an idempotency key, with the session
+when ids can repeat across sessions (see
+[Consumers can run twice](/server/consumers#consumers-can-run-twice)), or add
+fencing in the external system.
 
 ## Lanes
 

package/docs/stores/01-overview.mdx

@@ -20,6 +20,7 @@ export const ordersServer = createServer({
 | Store | Use it for |
 | --- | --- |
 | [Redis](/stores/redis) | Production (recommended) |
+| [Valkey](/stores/valkey) | Production, on node-redis: rotating credentials, TLS and reconnect control |
 | [Redis over HTTP](/stores/redis-http) | Production, when your provider only offers a REST API |
 | [Postgres](/stores/postgres) | Production |
 | [SQLite](/stores/sqlite) | Development: the default |

package/docs/stores/02-redis.mdx

@@ -21,9 +21,11 @@ export const ordersServer = createServer({
 npm i ioredis
 ```
 
-Works on a single Redis instance and on non-cluster providers such as Upstash,
-which is durable by default (use its TCP `rediss://` URL). There's nothing to
-set up: A2 creates its keys as it writes.
+Works on a single Redis or Valkey instance and on non-cluster providers such as
+Upstash, which is durable by default (use its TCP `rediss://` URL). There's
+nothing to set up: A2 creates its keys as it writes. For rotating credentials or
+custom TLS and reconnect settings, use the same store on node-redis:
+[Valkey](/stores/valkey).
 
 ## Options
 
@@ -31,22 +33,28 @@ set up: A2 creates its keys as it writes.
 | --- | --- |
 | `url` | creates an `ioredis` client |
 | `client` | your own `ioredis` client instead |
-| `keyPrefix` | isolates several apps on one Redis. Default `'a2'` |
+| `keyPrefix` | isolates several apps on one Redis. Default `'a2'`; no braces |
 | `clock`, `ids` | test seams for timestamps and generated event ids |
 
 ## Upgrade
 
 The store records its key layout in `<keyPrefix>:schema`, and refuses a prefix
 marked with another one with `STORE_NOT_CONFIGURED`. A release that changes
-the layout says what to do on its [upgrade page](/upgrades/overview).
-[0.21](/upgrades/0-21) reads what earlier releases wrote under the same
-prefix.
+the layout says what to do on its [upgrade page](/upgrades/overview). This
+release names every key differently from earlier ones, so give the store a
+fresh `keyPrefix`.
 
 ## How it works
 
-- Each session is a Redis Stream.
-- Every write publishes a wake-up, so live streams are push-driven, and
-  connections scale with your processes, not with your viewers.
+- Each session is a Redis Stream, and every key of a session shares one hash
+  tag.
+- Every write is one atomic script over its session's keys. On Upstash, which
+  runs a script under a database-wide lock by default, A2 marks each script to
+  lock only its session's keys. Redis and Valkey run one command at a time, so
+  A2 keeps scripts short instead.
+- Every write publishes a wake-up after its script, so live streams are
+  push-driven, and connections scale with your processes, not with your
+  viewers.
 - A wake-up is disposable: a safety re-read recovers a lost one within ten
   seconds.
 

package/docs/stores/03-redis-http.mdx

@@ -22,7 +22,8 @@ export const ordersServer = createServer({
 ```
 
 Stores sessions exactly like [Redis](/stores/redis), with no client dependency
-and nothing to set up. Use it when your provider only offers a REST API.
+and nothing to set up. Use it when your provider only offers a REST API. On
+Upstash, each script locks only its session's keys, never the whole database.
 
 :::warning
 Live streams trust the messages on the store's `:notify` channels. Browsers
@@ -37,7 +38,7 @@ credentials that can also write the store.
 | Option | |
 | --- | --- |
 | `url`, `token` | your provider's REST endpoint and token |
-| `keyPrefix` | isolates several apps on one Redis. Default `'a2'` |
+| `keyPrefix` | isolates several apps on one Redis. Default `'a2'`; no braces |
 | `clock`, `ids` | test seams for timestamps and generated event ids |
 
 ## Live updates
@@ -46,8 +47,9 @@ credentials that can also write the store.
   same URL and token. Each active channel holds one outbound HTTP subscription
   per store instance, shared by its viewers and closed when the last one
   leaves.
-- Writes publish their wake-ups in the same Redis script as the append. A
-  rejected notification doesn't fail the write.
+- Each write publishes its wake-up after its script commits, so a slow
+  subscriber never holds the script's lock. A rejected notification doesn't
+  fail the write.
 - Idle streams re-read every ten seconds to recover a missed notification.
   Subscriptions reconnect on their own and catch up from the event cursor.
 - After a reconnect, A2 re-reads presence and clears fields deleted during the

package/docs/stores/04-postgres.mdx

@@ -38,8 +38,8 @@ another role needs `grant execute on function a2_batch(text[], jsonb)` beside
 its grants on the tables, and keeps it when you apply the file again.
 
 A2 checks nothing up front. It relies on the table and column names, the
-column types, the primary keys, the unique index on `a2_events.event_id`, and
-the `a2_batch` function; the other indexes keep its queries fast. A query that
+column types, the primary keys, the unique index on `a2_events (session_id,
+event_id)`, and the `a2_batch` function; the other indexes keep its queries fast. A query that
 finds a table, column, or the function missing throws `STORE_NOT_CONFIGURED`,
 naming the file. Once it's applied, the next request works, with no redeploy.
 

package/docs/stores/07-valkey.mdx

@@ -0,0 +1,97 @@
+---
+title: Valkey
+description: The Redis store on node-redis, for Valkey and Redis servers that need TLS settings, rotating credentials, or reconnect control.
+---
+
+```ts server/orders.ts
+import { createServer } from 'experimental-a2/server'
+import { valkey } from 'experimental-a2/store-valkey'
+import { orders } from '@/contracts'
+
+export const ordersServer = createServer({
+  contract: orders,
+  store: valkey({ url: process.env.VALKEY_URL }),
+  consumers: [
+    /* ... */
+  ],
+})
+```
+
+```package-install
+npm i redis
+```
+
+Stores sessions exactly like [Redis](/stores/redis), on
+[node-redis](https://github.com/redis/node-redis) connections instead of
+`ioredis`. Use it with Valkey or Redis when a URL isn't enough: managed
+servers such as ElastiCache that authenticate with short-lived tokens, custom
+TLS settings, or your own reconnect and timeout policy. It needs a single
+server or a non-cluster replication group: it holds one non-cluster
+connection for commands and one for pub/sub.
+
+## Options
+
+| Option | |
+| --- | --- |
+| `url` | a `redis://` or `rediss://` URL |
+| `clientOptions` | node-redis `createClient` options for both connections, such as `socket`, `credentialsProvider`, `commandOptions`, `disableOfflineQueue` |
+| `keyPrefix` | isolates several apps on one server. Default `'a2'` |
+| `clock`, `ids` | test seams for timestamps and generated event ids |
+
+Pass `url`, `clientOptions`, or both; `url` wins over `clientOptions.url`.
+A2 always connects with `RESP: 2`, so `clientOptions` has no `RESP`, nor the
+options that need RESP3 (`clientSideCache`, `emitInvalidate`,
+`maintNotifications`).
+
+## Rotating credentials
+
+An async credentials provider runs each time a connection authenticates,
+including every reconnect, so each one gets a fresh token:
+
+```ts server/store.ts
+import { valkey } from 'experimental-a2/store-valkey'
+
+export const store = valkey({
+  clientOptions: {
+    socket: { host: 'my-cache.example.com', port: 6379, tls: true },
+    credentialsProvider: {
+      type: 'async-credentials-provider',
+      credentials: async () => {
+        // your token source, such as an ElastiCache IAM auth token:
+        // const password = await createAuthToken()
+        const password = 'token'
+        return { username: 'a2', password }
+      },
+    },
+  },
+})
+```
+
+## Connections
+
+A2 creates two clients from your options: one for commands, on the first
+store call, and one subscriber, on the first live stream or presence
+subscription. Every live stream and presence subscription in the process
+shares that subscriber. `close()` destroys both.
+
+- A new client is used once it first connects: calls wait for it, each for at
+  most `commandOptions.timeout` (five seconds without one), so a cold start
+  works with `disableOfflineQueue`.
+- While a client reconnects, node-redis's own options decide what happens to
+  commands: they wait in its offline queue, bounded by
+  `commandOptions.timeout`, or fail at once with `disableOfflineQueue`. A2
+  applies the same rules to a new live stream's subscription, which node-redis
+  would otherwise queue without a bound.
+- A reconnect follows your `socket.reconnectStrategy`. When the subscriber
+  reconnects, every live stream reads what it missed right away, without
+  waiting for the safety re-read.
+- When a client's reconnect strategy gives up, A2 replaces it: the command
+  client on the next store call, the subscriber on the next new live stream or
+  presence subscription. Until then, live streams still deliver within the
+  ten-second safety re-read.
+- A2 listens for each client's `'error'` events, so a dropped socket never
+  crashes the process. Failures surface as `STORE_UNAVAILABLE` from the call
+  that hit them.
+
+The upgrade rules, key layout, and per-command costs are the same as
+[Redis](/stores/redis).

package/docs/upgrades/01-overview.mdx

@@ -7,6 +7,7 @@ description: What to do when you move to a new release. One page per release tha
 
 | Release | What you do |
 | --- | --- |
+| [0.22](/upgrades/0-22) | Event ids are unique per session. Postgres: apply the new `schema.sql`, then deploy. Redis: use a new `keyPrefix`. |
 | [0.21](/upgrades/0-21) | Rewrite handlers as consumers. Let earlier deployments finish; on Postgres, then apply the new `schema.sql`. SQLite starts fresh. |
 | [0.20](/upgrades/0-20) | Postgres: apply `schema.sql` yourself, before you deploy. |
 | [0.19](/upgrades/0-19) | Start new agent sessions: earlier ones don't fold. |

package/docs/upgrades/78-0-22.mdx

@@ -0,0 +1,115 @@
+---
+title: '0.22'
+description: Event ids are unique per session, not per store, and a presence clear keeps its stamp.
+---
+
+## Event ids are unique per session
+
+The same event id in two sessions is now two events. Before, appending an id
+that another session already used threw `PARTIAL_DUPLICATE_BATCH`. Inside one
+session nothing changes: an identical retry returns the original rows, a batch
+that mixes sent and fresh events throws, and a consumer's retried completion
+returns the events it committed.
+
+- **Ids you derive need only the session's scope.** An
+  [`idempotentId()`](/reference/core#idempotentidparts) recipe that includes
+  the session still works; one that leaves it out no longer collides with
+  another session's events.
+- **Idempotency keys built from ids.** `event.id` and an actor's `ctx.id` are
+  unique within their session. Ids your callers pick, and the ids A2 derives
+  from them, can now repeat in another session, so a key for an external side
+  effect built from one alone can too. When yours can repeat, add the session
+  to the key; see
+  [Consumers can run twice](/server/consumers#consumers-can-run-twice).
+- **Clear markers** follow the same rule.
+- **Custom stores** check ids against the session's own rows only: the
+  idempotent-replay and partial-batch checks in `append` and
+  `completeAttempt` ignore other sessions. See
+  [`A2Store`](/reference/server#a2store).
+
+## Postgres
+
+0.22's `schema.sql` replaces the unique index on `a2_events (event_id)`,
+`a2_events_event_id`, with one on `a2_events (session_id, event_id)`,
+`a2_events_session_event_id`. Every row is kept, and building the new index
+can't fail: the old one already keeps those pairs unique.
+
+1. **Apply 0.22's `schema.sql`**, as the role your app connects with:
+   `node_modules/experimental-a2/sql/postgres/schema.sql`.
+2. **Deploy 0.22.**
+
+The first time it runs, the swap locks `a2_events` against every read and write
+until the new index is built, then drops the old one. On a large table, make
+both changes by hand instead, with nothing blocked. Run each statement on its
+own, outside a transaction:
+
+```sql
+create unique index concurrently if not exists a2_events_session_event_id
+  on a2_events (session_id, event_id);
+```
+
+A concurrent build that fails leaves an invalid index of the same name behind.
+Check that this returns `true` before you drop the old index; if it doesn't,
+drop the new one and build it again:
+
+```sql
+select indisvalid from pg_index
+ where indexrelid = 'a2_events_session_event_id'::regclass;
+```
+
+```sql
+drop index concurrently if exists a2_events_event_id;
+```
+
+Then apply `schema.sql`: it finds both done and waits on nothing. It drops the
+old index only once the new one is valid.
+
+With Drizzle, update your copy of `drizzle-schema.ts`:
+`a2_events_session_event_id` on `(session_id, event_id)` replaces
+`a2_events_event_id`. On a large table, run the statements above by hand
+instead, and take them out of the migration Drizzle generates.
+
+## SQLite
+
+Nothing to do. The store creates the new index and drops the old one when it
+opens the file. Once 0.22 has opened a file, don't open it with an earlier
+release: that release builds the old index again, and can't open the file at
+all once two sessions share an id.
+
+## Redis
+
+Redis names every key differently in this release, so it starts fresh:
+**point the store at a new `keyPrefix`**, then deploy. Under its new prefix,
+0.22 never reads what an earlier release wrote; delete the old prefix's keys
+whenever convenient. On a prefix 0.21 wrote, 0.22 refuses to start with
+`STORE_NOT_CONFIGURED`. A `keyPrefix` can't contain braces.
+
+What changes:
+
+- **Scripts lock only their session on Upstash.** Every key of a session
+  shares one hash tag, so each script sets Upstash's `allow-key-locking` and
+  locks its session's keys instead of the whole database. The store asks the
+  server once whether it accepts the flag; Redis and Valkey don't, and run one
+  command at a time anyway.
+- **No script publishes.** Each write publishes its wake-up after its script,
+  so a slow subscriber never holds a lock.
+- **`clear()` works on Upstash.** It used to rename the log aside, which
+  Upstash refuses for streams. The marker now joins the same log, and the old
+  lifetime's entries stay below it, unread, until `clear()` finishes deleting
+  them. A session that stays empty after its clear keeps only its clear marker,
+  the log holding it, and its log consumers' positions.
+
+## Memory
+
+Nothing to do: the memory store starts empty in every process.
+
+## Presence clears keep their stamp
+
+A `null` from `setPresence()` now leaves a tombstone in the store, carrying the
+clear's `at`, until the field's TTL runs out. An older value that reaches the
+store after the clear, such as one sent through another server instance, still
+loses. Before, it brought the field back. Nothing to do: Postgres and SQLite
+keep tombstones in `a2_presence` as a JSON `null` value.
+
+Custom stores with presence keep a tombstone for each `null`, compare it by
+`at` like a value until it expires, and leave tombstones out of `read`.

package/examples/playground/app/a0/sandbox.ts

@@ -68,6 +68,7 @@ async function openApp(appId: string): Promise<Sandbox> {
       persistent: true,
       snapshotExpiration: SNAPSHOT_EXPIRATION_MS,
       keepLastSnapshots: { count: 1 },
+      onResume: startDev,
     })
   } catch (error) {
     // Another instance created it first. The API holds a racing create until
@@ -81,8 +82,54 @@ async function openApp(appId: string): Promise<Sandbox> {
   return sandbox
 }
 
-// Parallel tool calls on a new app share one create within this instance.
-const opening = new Map<string, Promise<Sandbox>>()
+// Each instance keeps one handle per app, so parallel tool calls share an
+// open and later ones skip the lookup. A handle resumes a stopped session on
+// its next call; a deleted sandbox fails with a 404 until it's forgotten.
+// An empty app's idle check deletes its sandbox from whichever instance runs
+// it, 10 minutes after the sandbox opened. By then the session's 15 minutes
+// leave less than KEEP_ALIVE_MS, so every call extends it, and the extension's
+// 404 is how a kept handle finds out.
+const handles = new Map<string, Promise<Sandbox>>()
+const MAX_HANDLES = 100
+
+const forget = (appId: string): void => {
+  handles.delete(appId)
+}
+
+const open = (appId: string): Promise<Sandbox> => {
+  const opened = openApp(appId)
+  opened.catch(() => {
+    if (handles.get(appId) === opened) forget(appId)
+  })
+  return opened
+}
+
+const kept = (appId: string): Promise<Sandbox> => {
+  const pending = handles.get(appId) ?? open(appId)
+  // Most recently used last, so the cap drops the stalest.
+  handles.delete(appId)
+  handles.set(appId, pending)
+  const stalest = handles.keys().next().value
+  if (handles.size > MAX_HANDLES && stalest !== undefined) forget(stalest)
+  return pending
+}
+
+/**
+ * Whether the sandbox is still there. Extends it only by the shortfall, so
+ * repeated calls never stack up time.
+ */
+const keepAlive = async (sandbox: Sandbox): Promise<boolean> => {
+  const shortfall =
+    Date.now() + KEEP_ALIVE_MS - (sandbox.expiresAt?.getTime() ?? 0)
+  if (shortfall <= 0) return true
+  try {
+    await sandbox.extendTimeout(shortfall)
+  } catch (error) {
+    // Throws past the plan's session limit; the sandbox still works until then.
+    return !notFound(error)
+  }
+  return true
+}
 
 /** The app's sandbox, created or resumed, and kept up while it's used. */
 export async function appSandbox({
@@ -90,16 +137,13 @@ export async function appSandbox({
 }: {
   appId: string
 }): Promise<Sandbox> {
-  const pending =
-    opening.get(appId) ?? openApp(appId).finally(() => opening.delete(appId))
-  opening.set(appId, pending)
+  const pending = kept(appId)
   const sandbox = await pending
-  // Extends only by the shortfall, so repeated calls never stack up time.
-  const shortfall =
-    Date.now() + KEEP_ALIVE_MS - (sandbox.expiresAt?.getTime() ?? 0)
-  // Throws past the plan's session limit; the sandbox still works until then.
-  if (shortfall > 0) await sandbox.extendTimeout(shortfall).catch(() => {})
-  return sandbox
+  if (await keepAlive(sandbox)) return sandbox
+  if (handles.get(appId) === pending) forget(appId)
+  const reopened = await kept(appId)
+  await keepAlive(reopened)
+  return reopened
 }
 
 // A server that's booting refuses connections for a moment, and a page
@@ -118,12 +162,12 @@ export async function ensureApp({
   appId: string
 }): Promise<{ up: boolean; createdAt: Date }> {
   const sandbox = await appSandbox({ appId })
-  const probe = await sandbox.runCommand({
+  const answer = await sandbox.runCommand({
     cmd: 'bash',
     args: ['-c', `${START_DEV}; ${PROBE}`],
   })
   return {
-    up: Number(await probe.stdout()) > 0,
+    up: Number(await answer.stdout()) > 0,
     createdAt: sandbox.createdAt,
   }
 }
@@ -145,6 +189,7 @@ export async function deleteAppSandbox({
 }: {
   appId: string
 }): Promise<void> {
+  forget(appId)
   try {
     const sandbox = await Sandbox.get({
       name: sandboxName(appId),

package/examples/playground/app/a2slack/db/a2.ts

@@ -7,9 +7,9 @@
  * your schema.
  *
  * Whatever creates them, A2 relies on the table and column names, the column
- * types, the primary keys, and the unique index on a2_events.event_id. The
- * other indexes keep its queries fast. Every name is spelled out, so Drizzle's
- * `casing` setting changes none of them.
+ * types, the primary keys, and the unique index on a2_events (session_id,
+ * event_id). The other indexes keep its queries fast. Every name is spelled
+ * out, so Drizzle's `casing` setting changes none of them.
  *
  * A2's tables change only when a release's changelog says so; compare your
  * copy with that release's file. Drizzle can't declare functions or
@@ -48,7 +48,10 @@ export const a2Events = pgTable(
       name: 'a2_events_pkey',
       columns: [table.sessionId, table.idx],
     }),
-    uniqueIndex('a2_events_event_id').on(table.eventId),
+    uniqueIndex('a2_events_session_event_id').on(
+      table.sessionId,
+      table.eventId,
+    ),
     index('a2_events_types').on(table.sessionId, table.eventType, table.idx),
   ],
 )

package/examples/playground/app/a2slack/db/migrations/0004_a2_session_event_ids.sql

@@ -0,0 +1,2 @@
+CREATE UNIQUE INDEX "a2_events_session_event_id" ON "a2_events" USING btree ("session_id","event_id");--> statement-breakpoint
+DROP INDEX "a2_events_event_id";