@authhero/kysely-adapter 12.7.0 → 12.8.0

package/dist/types/src/cleanup.d.ts

@@ -1,6 +1,7 @@
 import { Kysely } from "kysely";
 import { Database } from "./db";
 import { SessionCleanupParams } from "@authhero/adapter-interfaces";
+export declare const MAX_BATCHES = 300;
 /**
  * Create a scoped session cleanup function that can filter by tenant and/or user.
  * This is designed for lazy cleanup after login session creation.
@@ -12,5 +13,24 @@ import { SessionCleanupParams } from "@authhero/adapter-interfaces";
  * independently without expensive subqueries to check for active children.
  *
  * Records are deleted only after they have been expired for the grace period (1 week).
+ *
+ * The tables are swept round-robin rather than one after another: draining them
+ * in a fixed order lets a backlog in the first table consume the whole batch
+ * budget, which is how login_sessions went unswept for months while
+ * refresh_tokens stayed clean. A sweep that throws — a PlanetScale statement
+ * timeout, say — is marked failed and skipped, but does not abort the others;
+ * one unhealthy table must not starve the rest.
+ *
+ * refresh_tokens and sessions expire on either of two columns, and each gets
+ * its own statement rather than one `OR`: MySQL declines to index_merge across
+ * OR'd predicates and falls back to a full scan, which on a production-sized
+ * table exceeds PlanetScale's 20s statement timeout and deletes nothing. Split,
+ * every statement is a clean single-column index range. This is the same
+ * reasoning — and the same fix — as codes/cleanup.ts.
+ *
+ * login_sessions is swept first because login_sessions_session_fk is
+ * ON DELETE CASCADE: every sessions row deleted cascade-deletes its
+ * login_sessions children, so draining the child table first makes the
+ * subsequent sessions batches far cheaper.
  */
 export declare function createSessionCleanup(db: Kysely<Database>): (params?: SessionCleanupParams) => Promise<void>;

package/dist/types/src/helpers/database-type.d.ts

@@ -0,0 +1,15 @@
+import { Kysely } from "kysely";
+import { Database } from "../db";
+export type DatabaseType = "mysql" | "sqlite";
+/**
+ * Probe which engine the adapter is talking to.
+ *
+ * `VERSION()` exists on MySQL and not on SQLite, so a thrown statement is the
+ * signal. Callers should memoize the result per adapter instance — the answer
+ * cannot change for a given `Kysely` connection.
+ *
+ * This matters for chunked deletes: `DELETE ... LIMIT` requires SQLite to be
+ * built with `SQLITE_ENABLE_UPDATE_DELETE_LIMIT`, which is not the default, so
+ * SQLite deployments take the unchunked path instead.
+ */
+export declare function getDatabaseType(db: Kysely<Database>): Promise<DatabaseType>;

package/dist/types/src/users/createMany.d.ts

@@ -0,0 +1,4 @@
+import { Kysely } from "kysely";
+import { Database } from "../db";
+import { User, UserInsert, WriteOptions } from "@authhero/adapter-interfaces";
+export declare function createMany(db: Kysely<Database>): (tenantId: string, users: UserInsert[], options?: WriteOptions) => Promise<User[]>;