[Upd4ting]

Why

A route registered as DefaultRoutes.WithOptions(DefaultRoutes.Edit, { index: "slug" }) should edit the row the index finds. It found that row, then wrote the update to the row whose primary key equals id. Usually no such row exists, so the edit was silently lost and the route still answered 200 with the old row. Fixes #90.

What changes

• editRow in src/index.ts takes the primary key (_id) of the row it found, asserts it is a string, and uses it for the update and for the read-back. Reading back by primary key also gives the right answer when the edit changes the indexed field itself. The old read through the index returned the unchanged row in that case.
• Without index the behaviour is the same as before, because the found row's _id is the requested id.
• docs/3.routes.md describes the fixed behaviour in the Edit options table.
• The verify journey issue-90-edit-index is renamed from "fails on purpose" to a guard, and features/README.md no longer lists it as failing.

flowchart LR
  R["PUT /edit?id=hello (index: slug)"] --> G["Query.Get(table, id, index)"]
  G -->|stored row, _id a1| W["WriteProperties + Lock"]
  W --> U_old["before: table.get('hello').update"]
  W --> U_new["after: table.get(stored._id).update"]
  U_new --> Rd["readRow by stored._id"]

Loading

Proof

src/tests/index/edit_index.test.ts drives the route against the in-memory MongoDB. One row's _id equals the indexed value, so an implementation that writes to the primary-key row fails the test.

Before, with main's src/index.ts:

  Edit with the index option
[2026-11-08 03:46:25] [ERROR] HTTP 500 PUT /edit-index/edit?id=hello: After applying the update, the (immutable) field '_id' was found to have been altered to _id: "a1"
    1) updates the row the index finds, not the row whose primary key is the id
    2) answers with the edited row when the edit changes the indexed field


  0 passing (93ms)
  2 failing

  1) Edit with the index option
       updates the row the index finds, not the row whose primary key is the id:

      AssertionError: expected 500 to equal 200
      + expected - actual

      -500
      +200
      

  2) Edit with the index option
       answers with the edited row when the edit changes the indexed field:

      AssertionError: expected { slug: 'rename-me', title: 'Before' } to have deep property 'slug' of 'renamed', but got 'rename-me'
      + expected - actual

      -rename-me
      +renamed
      

After:

  Edit with the index option
    ✔ updates the row the index finds, not the row whose primary key is the id (53ms)
    ✔ answers with the edited row when the edit changes the indexed field


  2 passing (152ms)

pnpm run checks prints Checks: 8 passed, 0 failed.

antelopejs-verify at 0d0e4a1, before the rebases, every feature plan lists: route-options/issue-90-edit-index passes. The only failures were issue-92-getter-mode and issue-93-multi-foreign, which #117 and #116 have since fixed on main. With #90 fixed too, features/README.md no longer lists any journey that fails on purpose.

After the rebase onto f4872d3, pnpm run checks prints Checks: 9 passed, 0 failed. and both new tests pass.