@stonyx/orm 0.3.2-alpha.63 → 0.3.2-alpha.64

package/dist/utils.d.ts

@@ -5,47 +5,3 @@ export declare function isDbError(error: unknown): error is {
 };
 export declare function isOrmRecord(value: unknown): value is OrmRecord;
 export declare function pluralize(word: string): string;
-/**
- * The highest NUMERIC id held by a set of records, or `0` when there is none.
- *
- * ONE COPY, and the duplication it replaces is the reason it lives here. Three
- * near-identical reduces existed at once: `assignRecordId` (server-assigned id
- * selection), `StandaloneDB.create` (src/standalone-db.ts) and the #203 test
- * helper. `docs/improvements.md`'s standing WET Code category prescribes
- * exactly this remedy -- extract into the module that already acts as the
- * shared utility -- and `assignRecordId` already imported `isOrmRecord` from
- * here.
- *
- * NON-NUMBERS ARE SKIPPED RATHER THAN COERCED TO `0`, AND THAT IS STYLISTIC.
- * `StandaloneDB`'s shape mapped them to `0`, which can never beat a seed of
- * `0`. Measured over eleven input classes (`[]`, `1`, `NaN`, `'5'`, `'abc'`,
- * `-3`, `0`, `null`, `undefined`, `Infinity`, and mixed arrays) the two shapes
- * produce IDENTICAL output on every one. In particular `typeof NaN` is
- * `'number'`, so NEITHER shape coerces `NaN` -- both reject it on `NaN > max`,
- * which is `false`. An earlier revision of this code asserted that the skip was
- * what made the `NaN` case work; it is not, the comparison is, and that claim
- * has been removed rather than left standing.
- *
- * WHAT IS LOAD-BEARING is that this is not `Math.max(...ids)`. `Math.max`
- * returns `NaN` if any operand is `NaN`, and a record CAN be held under the key
- * `NaN` -- so the obvious fix assigns `NaN`, lands on that slot and overwrites
- * it, which is abofs/stonyx-orm#203 in a new disguise. Pinned by
- * test/unit/assign-record-id-test.ts AC2; before that file existed the whole
- * suite scored 951/0 under exactly that fix.
- */
-export declare function maxNumericId(records: {
-    id?: unknown;
-}[]): number;
-/**
- * The message prefix `assignRecordId` throws with when no free id can be
- * derived for a model, and the ONE string `createHandler` matches on to answer
- * `409` instead of letting the rejection reach express's default handler.
- *
- * It lives here rather than in either file because both need it and neither
- * should own a copy: a literal in two places is how the two id coercions in
- * orm-request.ts drifted apart (see `coerceId`). The repo has no error codes
- * and no custom error classes -- 24 bare `throw new Error` sites across `src/`
- * -- so a shared prefix is the narrowest way to make ONE failure distinguishable
- * without inventing an error taxonomy this codebase does not use.
- */
-export declare const NO_FREE_ID_ERROR = "Cannot assign record ID: no free id available";

package/dist/utils.js

@@ -15,50 +15,3 @@ export function pluralize(word) {
     }
     return basePluralize(word);
 }
-/**
- * The highest NUMERIC id held by a set of records, or `0` when there is none.
- *
- * ONE COPY, and the duplication it replaces is the reason it lives here. Three
- * near-identical reduces existed at once: `assignRecordId` (server-assigned id
- * selection), `StandaloneDB.create` (src/standalone-db.ts) and the #203 test
- * helper. `docs/improvements.md`'s standing WET Code category prescribes
- * exactly this remedy -- extract into the module that already acts as the
- * shared utility -- and `assignRecordId` already imported `isOrmRecord` from
- * here.
- *
- * NON-NUMBERS ARE SKIPPED RATHER THAN COERCED TO `0`, AND THAT IS STYLISTIC.
- * `StandaloneDB`'s shape mapped them to `0`, which can never beat a seed of
- * `0`. Measured over eleven input classes (`[]`, `1`, `NaN`, `'5'`, `'abc'`,
- * `-3`, `0`, `null`, `undefined`, `Infinity`, and mixed arrays) the two shapes
- * produce IDENTICAL output on every one. In particular `typeof NaN` is
- * `'number'`, so NEITHER shape coerces `NaN` -- both reject it on `NaN > max`,
- * which is `false`. An earlier revision of this code asserted that the skip was
- * what made the `NaN` case work; it is not, the comparison is, and that claim
- * has been removed rather than left standing.
- *
- * WHAT IS LOAD-BEARING is that this is not `Math.max(...ids)`. `Math.max`
- * returns `NaN` if any operand is `NaN`, and a record CAN be held under the key
- * `NaN` -- so the obvious fix assigns `NaN`, lands on that slot and overwrites
- * it, which is abofs/stonyx-orm#203 in a new disguise. Pinned by
- * test/unit/assign-record-id-test.ts AC2; before that file existed the whole
- * suite scored 951/0 under exactly that fix.
- */
-export function maxNumericId(records) {
-    return records.reduce((max, record) => {
-        const { id } = record;
-        return typeof id === 'number' && id > max ? id : max;
-    }, 0);
-}
-/**
- * The message prefix `assignRecordId` throws with when no free id can be
- * derived for a model, and the ONE string `createHandler` matches on to answer
- * `409` instead of letting the rejection reach express's default handler.
- *
- * It lives here rather than in either file because both need it and neither
- * should own a copy: a literal in two places is how the two id coercions in
- * orm-request.ts drifted apart (see `coerceId`). The repo has no error codes
- * and no custom error classes -- 24 bare `throw new Error` sites across `src/`
- * -- so a shared prefix is the narrowest way to make ONE failure distinguishable
- * without inventing an error taxonomy this codebase does not use.
- */
-export const NO_FREE_ID_ERROR = 'Cannot assign record ID: no free id available';

package/package.json

@@ -4,7 +4,7 @@
     "stonyx-async",
     "stonyx-module"
   ],
-  "version": "0.3.2-alpha.63",
+  "version": "0.3.2-alpha.64",
   "description": "",
   "main": "dist/index.js",
   "type": "module",

package/src/manage-record.ts

@@ -2,7 +2,7 @@ import Orm, { store } from '@stonyx/orm';
 import OrmRecord from './record.js';
 import { getGlobalRegistry, getPendingRegistry, getPendingBelongsToRegistry, getBelongsToRegistry, getHasManyRegistry } from './relationships.js';
 import type Serializer from './serializer.js';
-import { isOrmRecord, maxNumericId, NO_FREE_ID_ERROR } from './utils.js';
+import { isOrmRecord } from './utils.js';
 
 interface CreateRecordOptions {
   isDbRecord?: boolean;
@@ -195,58 +195,17 @@ export function updateRecord(record: OrmRecord, rawData: unknown, userOptions: C
 }
 
 /**
- * gets the next available id, based on the HIGHEST id present.
+ * gets the next available id based on last record entry.
  *
  * In MySQL mode with numeric IDs, assigns a temporary pending ID.
  * MySQL's AUTO_INCREMENT provides the real ID after INSERT.
- *
- * ---------------------------------------------------------------------------
- * WAS: `Array.from(storeMap.values()).at(-1).id + 1` — the LAST INSERTED id,
- * not the maximum (abofs/stonyx-orm#203). The store is a Map, so insertion
- * order stops being ascending the moment a record is deleted and recreated, a
- * db.json is written out of order, a directory-mode store is read back in file
- * order, or a caller POSTs a high id and then a low one. After that, every
- * server-assigned id is one that is ALREADY TAKEN — and `createRecord`'s
- * last-entry-wins branch then overwrites that record IN PLACE and answers 200.
- * No error, no 409, and the store's size does not change. That is the whole
- * defect, and it is reachable from a create with NO id at all, which is the
- * most ordinary write a consumer performs.
- *
- * Covered by test/unit/assign-record-id-test.ts. Note for anyone changing this
- * function: before that file existed, the whole suite scored 951/0 both on the
- * defect and on a naive `Math.max` fix that introduced a second one. A green
- * suite is not evidence here; those assertions are.
- * ---------------------------------------------------------------------------
  */
 function assignRecordId(modelName: string, rawData: { [key: string]: unknown }): void {
-  // PRESENCE, not truthiness. `0` is a legal value for an `attr('number')` id,
-  // and `if (rawData.id) return` silently reassigned it, handing the caller back
-  // a different record than the one it named (#203).
-  //
-  // `''` is deliberately NOT honoured here and this is not an oversight: it is
-  // the one string that means "no id". `parseInt('')` is `NaN`, a record CAN be
-  // held under the key `NaN`, and orm-request.ts's body-id normalisation relies
-  // on `''` staying absent — otherwise `POST {"id":""}` answers 409 against a
-  // record it never named.
-  //
-  // WHAT WIDENING THIS TO `!== undefined` ACTUALLY DOES, measured rather than
-  // asserted: `{id: ''}` early-returns, `parseInt('')` NaNs it, and the record
-  // lands on the store's `NaN` slot and OVERWRITES whatever is there — #203's
-  // own defect class. It does NOT turn access-filter-enforcement-test.ts
-  // assertion 44 red; an earlier revision of this comment claimed it did, which
-  // converted an unknown into a false assurance. AC6's BOUNDARY assertions are
-  // what catch it, and they only do so because they seed the `NaN` slot first.
-  if (rawData.id || rawData.id === 0) return;
+  if (rawData.id) return;
 
   // In SQL mode with numeric IDs, defer to database auto-increment.
   // Use unique negative integers — they survive the number transform (parseInt preserves negatives)
   // and avoid NaN store-key collisions that string pending IDs caused.
-  //
-  // This early return is ABOVE the max computation on purpose: a pending
-  // negative must never be a candidate for, or be perturbed by, the max path.
-  // Pinned directly (AC5.3) rather than by asserting the max is unaffected —
-  // that assertion could not have failed, because nothing negative ever reaches
-  // the code below.
   if (Orm.instance?.sqlDb && !isStringIdModel(modelName)) {
     rawData.id = -(++pendingIdCounter);
     rawData.__pendingSqlId = true;
@@ -256,218 +215,15 @@ function assignRecordId(modelName: string, rawData: { [key: string]: unknown }):
   const storeMap = store.get(modelName);
   if (!storeMap) throw new Error(`Cannot assign record ID: model "${modelName}" not found in store`);
   const modelStore = Array.from(storeMap.values()).filter(isOrmRecord);
-
-  // ONE COPY of the max-numeric-id reduce, in src/utils.ts. There were three
-  // (here, StandaloneDB.create, and the #203 test helper) and `docs/
-  // improvements.md`'s WET Code category prescribes the extraction. What that
-  // helper must NOT be is `Math.max(...ids)`; the reason is measured and it is
-  // documented at the helper rather than duplicated here. Pinned by AC2.
-  const maxId = maxNumericId(modelStore);
-
-  // THE OCCUPANCY CHECK RUNS ON THE LANDING KEY, NOT ON THE RAW CANDIDATE, and
-  // the difference is a silent data loss rather than a nicety.
-  //
-  // `createRecord` looks the record up under `rawData.id` (:50) but WRITES it
-  // under `record.id` (:69) — the value after the model's declared id transform
-  // has run inside `serialize`. When the transform is not the identity those two
-  // differ, so a guard written as `storeMap.has(rawData.id)` checks a key the
-  // record will never occupy, misses an occupied slot and overwrites it —
-  // measured on an `uppercase`-id model: the guard checks `owner-1`, the record
-  // lands under `OWNER-1`, store size unchanged, no error. That is
-  // abofs/stonyx-orm#205's lookup-key/landing-key divergence reappearing inside
-  // #203's own fix, which is why AC4 exists and why `rawData.id` is set to the
-  // LANDING key below.
-  //
-  // THE SCOPE OF THAT CLAIM, stated rather than implied. Setting `rawData.id` to
-  // the landing key makes :50 and :69 agree for every IDEMPOTENT id transform —
-  // `number`, `float`, `string`, `passthrough`, `uppercase`, `trim`. It does NOT
-  // make them agree for `date` or `timestamp`: `transforms.date` returns a NEW
-  // object every call and a `Map` keys by identity, so `storeMap.has(landingKey)`
-  // is always `false` there and the occupancy check is vacuous. `dev` is broken
-  // for those types too — this is not a regression — but no comment here may
-  // claim a property it was not measured to have (#212 § AC5).
-  //
-  // Resolved ONCE, outside the walk: `getIdType` instantiates the model class,
-  // so resolving it per candidate would put a model construction on every
-  // iteration of a loop that exists to walk past occupied slots.
-  const toStoreKey = storeKeyDeriver(modelName);
-
-  // DOES THIS MODEL FILE ITS RECORDS UNDER STRING KEYS? Decided by RUNNING the
-  // model's own id transform once, not by matching a type NAME against a list:
-  // `Orm.instance.transforms` (main.ts:70) is a public, MUTABLE instance
-  // property, so any enumeration of "the string-ish types" written here would be
-  // wrong the moment a consumer registers one.
-  const stringKeyed = typeof toStoreKey(maxId + 1) === 'string';
-
-  // THE CANDIDATE FOR A STRING-KEYED MODEL IS NOT A BARE NUMBER, and this is
-  // abofs/stonyx-orm#209 — which is REOPENED — not aesthetics.
-  //
-  // `orm-request.ts`'s `coerceId` (:322) resolves a NUMERIC-LOOKING string to a
-  // NUMBER on every id-bearing surface, while a model declaring
-  // `id = attr('string')` files under the STRING key. So a server-assigned `'1'`
-  // produces a record that is created and then NOT ADDRESSABLE. Measured over
-  // the route, owner store `{'1': ...}`:
-  //
-  //   GET    /owners/1       -> 404      (the record exists)
-  //   DELETE /owners/1       -> 404
-  //   GET    /owners/owner-1 -> 200
-  //
-  // and `_withHooks` (:1185) hands an after-`create` hook
-  // `context.record === undefined` for the same reason. `dev` assigned `'bob1'`,
-  // which is not numeric-looking, so `dev` has neither problem: a bare-number
-  // candidate would move #209 from "a caller supplied a numeric-looking id" onto
-  // the DEFAULT path for every server-assigned create on every string-id model.
-  // Prefixing with the model name keeps #209's population exactly as narrow as
-  // it already was, without touching the one shared coercion or the assertion
-  // that pins #209 open. Pinned by AC3.
-  const toCandidate = stringKeyed
-    ? (value: number) => `${modelName}-${value}`
-    : (value: number) => value;
-
-  // `maxId + 1` is the id AC1 pins: strictly greater than every numeric key
-  // present. IT IS NOT ALWAYS AVAILABLE, and that gap was a live denial of
-  // service. Float64 has no integer successor at or above 2^53, so
-  // `maxId + 1 === maxId` for every `maxId >= 9007199254740992` and `+ 1` inside
-  // the walk is a NO-OP there. One record filed under that key — which an
-  // unauthenticated `POST {"id":9007199254740992}` puts there, and which reaches
-  // even a filter-protected collection through has-many.ts:65 (#207), a channel
-  // GATE 0 does not cover — made the walk unable to advance, so it exhausted its
-  // budget and threw on EVERY subsequent server-assigned create, permanently,
-  // until that record was deleted. Measured over the route: 200, then 500 for
-  // every no-id create. `dev` answers 200.
-  //
-  // So a store holding one adversarial record must not disable its collection.
-  // When "above the max" is not a usable strategy the walk RESTARTS FROM 1: the
-  // store holds at most `size` keys, so one of `1 .. size + 1` is always free
-  // under an injective id transform. Pinned by AC7.
-  const start = maxId + 1;
-  let landingKey = firstFreeKey(storeMap, toStoreKey, toCandidate, start);
-
-  // THE RESTART, and it is the whole of the ceiling fix. Killing mutation:
-  // delete this block -> AC7 goes red (the route answers 409 instead of the
-  // created resource).
-  if (landingKey === NO_FREE_KEY && start !== 1) {
-    landingKey = firstFreeKey(storeMap, toStoreKey, toCandidate, 1);
-  }
-
-  if (landingKey === NO_FREE_KEY) {
-    // Reachable only with a NON-INJECTIVE id transform — see `firstFreeKey`.
-    // `createHandler` matches this message and answers 409 rather than letting it
-    // reach express's default handler, which serialises a stack trace with
-    // absolute install paths outside NODE_ENV=production (the hazard
-    // orm-request.ts:553-558 exists to name). Pinned by AC8.
-    throw new Error(`${NO_FREE_ID_ERROR} for model "${modelName}"`);
-  }
-
-  rawData.id = landingKey;
+  const lastRecord = modelStore.at(-1);
+  rawData.id = lastRecord ? (lastRecord.id as number) + 1 : 1;
 }
 
-// Returned instead of a key so that "no key" cannot be confused with a transform
-// that legitimately produced `undefined` or `null`.
-const NO_FREE_KEY = Symbol('no free store key');
-
-/**
- * The first store key at or above `start` that no record occupies, walking
- * candidate ids upward, or `NO_FREE_KEY` if the walk cannot reach one.
- */
-function firstFreeKey(
-  storeMap: Map<number | string, unknown>,
-  toStoreKey: (value: number | string) => number | string,
-  toCandidate: (value: number) => number | string,
-  start: number
-): number | string | typeof NO_FREE_KEY {
-  let candidate = start;
-  let landingKey = toStoreKey(toCandidate(candidate));
-  let attempts = 0;
-
-  while (storeMap.has(landingKey)) {
-    // THE BOUND IS EXACTLY TIGHT, not conservative: this walk tries
-    // `storeMap.size + 1` DISTINCT candidates against at most `storeMap.size`
-    // occupied keys, so under an injective `toStoreKey` it provably cannot fire.
-    // Under a non-injective one it provably terminates — and that is a reachable
-    // consumer state rather than a hypothesis: `transforms.boolean`
-    // (transforms.ts:4) collapses every candidate onto `true`/`false`, and
-    // `Orm.instance.transforms` (main.ts:70) is public and MUTABLE, so a consumer
-    // can register an arbitrary non-injective transform and name it as an id
-    // type. Without this, a no-id create spins forever inside a synchronous store
-    // walk and pins a worker, which is worse than either collision policy. Its
-    // EXISTENCE and its THRESHOLD are both pinned by AC8: deleting it makes AC8
-    // HANG rather than fail, and weakening it to fire on the first collision
-    // makes AC8.1 red.
-    if (++attempts > storeMap.size) return NO_FREE_KEY;
-
-    // NOTE FOR ANYONE ADDING A SECOND EXIT HERE. A `candidate + 1 === candidate`
-    // float-saturation check was written, measured, and REMOVED: with the
-    // restart-from-1 above in place, deleting the saturation check leaves the
-    // whole suite green, because the budget reaches the same `NO_FREE_KEY` one
-    // pass later and the restart still answers. An unkillable guard in a change
-    // whose deliverable is falsifiable coverage is exactly what this story exists
-    // to stop shipping. `+ 1` being a no-op at 2^53 costs `size` extra `Map.has`
-    // calls on that one path and changes no outcome.
-    candidate += 1;
-    landingKey = toStoreKey(toCandidate(candidate));
-  }
-
-  return landingKey;
-}
-
-/**
- * Returns the derivation that maps an id VALUE to the store KEY a record
- * carrying it will actually be filed under — the model's declared id transform,
- * the same one `serialize` runs at createRecord:68 before the `.set` at :69.
- */
-function storeKeyDeriver(modelName: string): (value: number | string) => number | string {
-  const idType = getIdType(modelName);
-  const transform = idType ? Orm.instance?.transforms?.[idType] : undefined;
-
-  // SURVIVOR, RETAINED, with its reachability condition stated rather than left
-  // silent — `docs/project-structure.md` § "unkillable code reads as coverage and
-  // is not" is the standing rule and it applies outside orm-request.ts too.
-  //
-  // No mutation in this repo can kill this branch, and that is STRUCTURAL rather
-  // than an untested gap: `Model` declares `id = attr('number')` (model.ts:15) so
-  // every registered model has an id type; `ModelProperty` refuses a type with no
-  // registered transform (model-property.ts:4) so a declared type always
-  // resolves; and `getIdType` can therefore only return `undefined` when
-  // `getRecordClasses` yields no `modelClass` — in which case `createRecord`
-  // throws at :62 a few lines later regardless, so no record is ever filed
-  // through this branch.
-  //
-  // BECOMES REACHABLE if a model can be declared without an `id` property, if a
-  // store map can exist for a model with no registered class, or if
-  // `createRecord` stops constructing the model class. Kept rather than deleted
-  // because the alternative on that path is a `transform is not a function`
-  // TypeError, and because identity is exactly what `createRecord` would file
-  // under when no transform exists — the two agree, which is the property AC4 is
-  // about.
-  if (typeof transform !== 'function') return value => value;
-
-  return value => {
-    try {
-      return transform(value) as number | string;
-    } catch {
-      // `uppercase` and `trim` (transforms.ts:11-12) call a string method on the
-      // value directly, so a NUMERIC candidate throws `value?.toUpperCase is not
-      // a function`. On `dev` they never saw one — `lastRecord.id + 1` on a
-      // string id is a string — so feeding them a number here would regress a
-      // legal, registered id type into an uncaught 500. The retry feeds the
-      // string form, which is the shape an id actually arrives in off a JSON body
-      // or a URL param. A transform that throws on BOTH shapes still propagates.
-      // Pinned by AC9.
-      return transform(String(value)) as number | string;
-    }
-  };
-}
-
-function getIdType(modelName: string): string | undefined {
-  const modelClass = Orm.instance?.getRecordClasses(modelName).modelClass as (new (name: string) => { [key: string]: unknown }) | undefined;
-  if (!modelClass) return undefined;
+function isStringIdModel(modelName: string): boolean {
+  const modelClass = Orm.instance.getRecordClasses(modelName).modelClass as (new (name: string) => { [key: string]: unknown }) | undefined;
+  if (!modelClass) return false;
 
   const model = new modelClass(modelName);
 
-  return (model.id as { type?: string } | undefined)?.type;
-}
-
-function isStringIdModel(modelName: string): boolean {
-  return getIdType(modelName) === 'string';
+  return (model.id as { type?: string } | undefined)?.type === 'string';
 }

package/src/orm-request.ts

@@ -98,8 +98,8 @@
  *
  * PASSING THE CONTEXT MAKES A MODEL-CORRECT ANSWER POSSIBLE. It does not make
  * the answer model-correct on its own -- the resolved predicate has to READ it.
- * Measured against this repo's own shipped access class, on a request express
- * dispatched to `GET /owners/angela`, asked about ANIMALS:
+ * Measured against an ARITY-1 predicate, on a request express dispatched to
+ * `GET /owners/angela`, asked about ANIMALS:
  *
  *     getAccess('animal')(ownersRequest, { model: 'animal', operation: 'read' })
  *       ->  record => record.id !== 'angela' && record.id !== 'restricted'
@@ -110,23 +110,30 @@
  * `['read', 'create', 'update', 'delete']`, a full CRUD grant. Either way the
  * context was supplied and the answer is not the animal answer, and it is wrong
  * in the GRANTING direction, because that predicate is arity-1 and identifies
- * its collection from the request. (The first of these is asserted on a live
- * dispatch by AC9 in test/integration/orm-test.ts.)
+ * its collection from the request. (Asserted on a live dispatch by AC9 in
+ * test/integration/orm-test.ts, against a deliberately arity-1 predicate.)
  *
- * Every predicate in this repo and in every consumer tree is arity-1 on the day
- * this ships, and the caller has no supported way to tell which kind it got --
- * the boot-time arity warning that would surface it is abofs/stonyx-orm#213.
+ * This repo's own sample access class has since been MIGRATED to read the
+ * context (abofs/stonyx-orm#222), so `getAccess('animal')` here now answers
+ * with the animal filter. That is not true of a consumer tree: an arity-1
+ * predicate keeps working -- the second argument is additive -- and the caller
+ * has no supported way to tell which kind it got. The boot-time arity warning
+ * that surfaces one is abofs/stonyx-orm#221.
  * So: pass the context, and do not treat a resolved predicate's answer as
  * model-specific until that predicate has been migrated to read the context.
  *
  * ---------------------------------------------------------------------------
  * DO NOT RECONSTRUCT THE REQUEST PATH INSIDE `access()`.
  * ---------------------------------------------------------------------------
- * `auth()` below hands your `access(request)` a raw transport artifact and asks
- * you to work out which collection it addresses. Every attempt to do that by
- * parsing the request target has failed OPEN. Five distinct variants of the
- * same three-line example have now been found, each after the previous was
- * fixed, by five different people:
+ * You do not have to. `auth()` below hands your predicate the ACCESS CONTEXT as
+ * argument two, and `context.model` already names the collection -- see the
+ * contract section above. Argument ONE is still the raw transport artifact, and
+ * everything from here to the end of this banner is the record of what happened
+ * when predicates worked the collection out from it. IT IS HISTORY, NOT
+ * GUIDANCE: do not write any of it into a new predicate. Every attempt to
+ * identify the collection by parsing the request target has failed OPEN. Five
+ * distinct variants of the same three-line example have now been found, each
+ * after the previous was fixed, by five different people:
  *
  *   1. `request.url` is mount-relative under `RestServer.mountRoute`, so a
  *      prefix match against it is ALWAYS false.
@@ -145,22 +152,43 @@
  *      last, and the record comes back in full. It walks past a hard
  *      `return false` deny the same way.
  *
- * The fix is not a sixth rule. It is to stop parsing:
+ * The fix is not a sixth rule, and it is not a better string to match. It is to
+ * stop identifying the collection at all: read `context.model`. That is a claim
+ * about IDENTIFYING THE COLLECTION, not about the sample as a whole -- the
+ * `/archived` SUB-PATH rule is still a string match, and abofs/stonyx-orm#228 is
+ * a sixth spelling that gets past it.
  *
- *   `request.baseUrl` is the mount Express ACTUALLY MATCHED when it dispatched
- *   the request. It carries no query string, it is not mount-relative, it is
- *   unaffected by absolute-form, and it already includes the configured
- *   `ORM_REST_ROUTE` prefix -- so there is nothing to derive and nothing to
- *   join. Compare it lower-cased (the router matched case-insensitively) and
- *   fail CLOSED when it is absent. Use `request.path` -- mount-relative and
- *   query-free -- if you need to distinguish sub-paths.
+ *   An intermediate revision of the sample read `request.baseUrl` -- the mount
+ *   Express ACTUALLY MATCHED. That closed all five variants (no query string,
+ *   not mount-relative, unaffected by absolute-form, already carrying the
+ *   configured `ORM_REST_ROUTE` prefix), but it was a transport artifact
+ *   standing in for a structural fact and the sample no longer does it.
+ *   `context.model` IS the structural fact, so all five variants are
+ *   unconstructible against a migrated predicate rather than handled.
+ *
+ * ONE READ OF ARGUMENT ONE SURVIVES, AND IT MUST: `request.path`. It is
+ * mount-relative and query-free, and it is for rules that distinguish SUB-PATHS
+ * beneath the mount. The context names which model and which verb, NOT which
+ * route, so the sample's `/archived` deny cannot be expressed from the context
+ * alone and a context-ONLY rewrite would silently turn that deny into an allow.
+ *
+ * NORMALISE THE WAY THE ROUTER DOES, AND CASE-FOLDING ALONE IS NOT THAT. The
+ * sample lower-cases before comparing, because a matcher stricter than the
+ * case-insensitive router can be stepped around. That closes the case gap only.
+ * Express sets `request.path` from the RAW, UNDECODED pathname while the router
+ * DECODES `:id`, so `GET /owners/%61rchived` reaches a `path === '/archived'`
+ * comparison as `/%61rchived` and walks past the deny. That gap is live in the
+ * sample and is tracked as abofs/stonyx-orm#228; the `.toLowerCase()` is not a
+ * complete normalisation recipe. Compare record ids at their real case.
  *
  * `?? ''` is not a defence. It converts an absent request target into an empty
  * string, which matches no collection, which falls through to the permission
- * array -- a total grant. An input you cannot identify must DENY.
+ * array -- a total grant. An input you cannot identify must DENY, and that
+ * applies to BOTH arguments: since #202 the guard and the read can sit on
+ * different objects, and a guard on argument two does not protect a read of
+ * argument one. The sample returns `false` for an absent `model` AND for an
+ * absent or non-string `request.path`, rather than falling through either way.
  *
- * THAT IS STILL A STOPGAP. `baseUrl` closes all five variants, but it is a
- * transport artifact being asked to stand in for a structural fact.
  * THE REAL FIX IS abofs/stonyx-orm#202: `access()` should receive the model,
  * the operation and the record. Prefer the array shape (`['read']`) or `false`
  * until #202 lands; the function shape is what requires any matching at all.
@@ -185,7 +213,7 @@ import type { HookContext } from './hooks.js';
 import config from 'stonyx/config';
 import log from 'stonyx/log';
 import type { OrmRecord, AccessContext, AccessFunction, AccessMethod, AccessOperation } from './types/orm-types.js';
-import { isOrmRecord, NO_FREE_ID_ERROR } from './utils.js';
+import { isOrmRecord } from './utils.js';
 
 interface OrmRequest$ extends Request {
   protocol?: string;
@@ -762,41 +790,7 @@ export default class OrmRequest extends Request {
       // only O(1) signal that distinguishes an insert from an overwrite.
       const slotsBefore = store.get(model)?.size ?? 0;
 
-      // THE ONE `createRecord` FAILURE THIS ROUTE ANSWERS RATHER THAN
-      // PROPAGATES, and it is narrow on purpose.
-      //
-      // `assignRecordId` throws when it cannot derive a free store key for a
-      // server-assigned id. Unguarded that rejection is auto-forwarded -- there
-      // is no catch here, none in @stonyx/rest-server's dispatcher
-      // (dist/request.js:41-70), and express 5 hands it to its default error
-      // handler, which serialises the STACK, with absolute install paths and the
-      // internal module graph, to an unauthenticated caller outside
-      // NODE_ENV=production. That is the hazard :553-558 already names in this
-      // file, and every sibling refusal in this handler returns an integer
-      // status instead. So this one returns 409, matching the client-duplicate
-      // refusal at :713: the caller asked for a record and the collection has no
-      // id to give it.
-      //
-      // MATCHED ON THE SHARED PREFIX, not on a literal, and NOT by catching
-      // everything: `createRecord` also throws for "ORM is not ready", a
-      // read-only view and an unregistered model store, and turning any of those
-      // into a 409 would report a configuration fault as a conflict. Anything
-      // else is re-thrown unchanged.
-      let created;
-
-      try {
-        created = createRecord(model, recordAttributes as { [key: string]: unknown }, { serialize: false, _skipAutoPersist: true });
-      } catch (error) {
-        if (!(error instanceof Error) || !error.message.startsWith(NO_FREE_ID_ERROR)) throw error;
-
-        // Not silently. A collection that can no longer assign an id is a
-        // configuration fault (a non-injective id transform), and a bare 409
-        // with no diagnostic is indistinguishable from an ordinary duplicate.
-        log.error?.(`[@stonyx/orm] ${error.message}`);
-
-        return 409; // Conflict
-      }
-
+      const created = createRecord(model, recordAttributes as { [key: string]: unknown }, { serialize: false, _skipAutoPersist: true });
       const record = isOrmRecord(created) ? created : null;
       if (!record) return 500;
 
@@ -821,32 +815,11 @@ export default class OrmRequest extends Request {
         //
         // Both conditions are required and neither implies the other:
         //   createdNewSlot -- the store grew, so this request inserted rather
-        //                     than overwrote. SURVIVOR AS OF #203, AND THAT IS
-        //                     WHAT THIS NOTE IS FOR. It used to be killable:
-        //                     `assignRecordId` returned last-INSERTED + 1, so a
-        //                     server-assigned id could land on an occupied slot,
-        //                     `createRecord` updated in place, and removing this
-        //                     half turned access-filter-enforcement-test.ts
-        //                     assertion 31 red. #203 closed that: the
-        //                     server-assigned path now walks past occupied keys,
-        //                     so no create reaching here can overwrite. Measured
-        //                     -- delete `createdNewSlot &&` below: `dev` gives
-        //                     55 pass / 1 fail with assertion 31 RED, this tree
-        //                     gives 56 pass / 0 fail, GREEN.
-        //                     KEPT ANYWAY, AND NOT FOR THE OLD REASON. Without
-        //                     it a denied create becomes `store.remove` on a key
-        //                     the caller may have influenced, which :815-820
-        //                     records as having been an unauthenticated deletion
-        //                     primitive across the whole id space. BECOMES
-        //                     KILLABLE AGAIN the moment any caller-supplied id
-        //                     can reach `createRecord` from this handler --
-        //                     which is exactly what has-many.ts:65 and
-        //                     belongs-to.ts:45 already do for ANOTHER model's
-        //                     store (abofs/stonyx-orm#207), and what a third
-        //                     un-stripped id channel would do for this one
-        //                     (#204). Do not delete it on the strength of #203
-        //                     being closed; that is the reasoning :862-867 warns
-        //                     about, one level up.
+        //                     than overwrote. Guards `assignRecordId` picking an
+        //                     id that is already taken (it returns
+        //                     last-INSERTED + 1, not max + 1, so a store whose
+        //                     insertion order is not ascending collides) -- see
+        //                     abofs/stonyx-orm#203.
         //   identity       -- the slot still holds the object we just created,
         //                     so nothing between createRecord and here replaced
         //                     it. Deleting this half SURVIVES the suite, and it

package/src/standalone-db.ts

@@ -8,10 +8,6 @@
 
 import fs from 'fs/promises';
 import path from 'path';
-// `./utils.js` pulls in `@stonyx/utils/string` and nothing else -- no ORM
-// bootstrap, no `@stonyx/orm` index, no side effects -- so the "no framework
-// dependencies" property above still holds.
-import { maxNumericId } from './utils.js';
 
 interface StandaloneDBOptions {
   dbPath?: string;
@@ -135,19 +131,12 @@ export default class StandaloneDB {
     const records = await this.readCollection(collection);
 
     if (!data.id) {
-      // SHARED WITH `assignRecordId` (src/manage-record.ts), which is the other
-      // place this repo picks a server-assigned id. It was a second copy of the
-      // reduce, and nothing here pointed at it — a maintainer editing this
-      // method could not discover the other existed. See `maxNumericId` for why
-      // it is not `Math.max` (abofs/stonyx-orm#203).
-      //
-      // THE TWO ARE NOT THE SAME FUNCTION beyond this line, deliberately.
-      // `StandaloneDB` has no model, id-type or transform concept, so `maxId + 1`
-      // IS its store key; `assignRecordId` has to map the candidate through the
-      // model's declared id transform first, and then walk past occupied keys.
-      // Transplanting this method's remaining logic into the ORM reproduces
-      // #203's landing-key defect exactly — which is what AC4 pins.
-      data.id = maxNumericId(records) + 1;
+      const maxId = records.reduce((max, r) => {
+        const rid = typeof r.id === 'number' ? r.id : 0;
+        return rid > max ? rid : max;
+      }, 0);
+
+      data.id = maxId + 1;
     }
 
     // Check for duplicate id