GrottoCenter / grottocenter-api / 40914603537

91%

push

github

test(entrance): cover concurrent plain permanent deletes of a named cave (#1901)

## 🤔 What

- Adds two regression tests to `test/integration/4_routes/Entrances/delete-concurrency.test.js` for the scenario in #1901:
  - two overlapping `DELETE /api/v1/entrances/:id?isPermanent=1` with no merge target, on a soft-deleted entrance whose cave has its own name: one request returns 200, the other 404, and no `t_name` row is left on the removed cave or entrance;
  - a single permanent delete where one `t_name` row has both `id_entrance` and `id_cave` set: the row is removed along with the cave.
- No production code change: the race was already fixed by #1899 (#1852).

## 🤷‍♂️ Why

The 500 in #1901 happened on 2026-10-10, eight days before #1899 was merged. At that time two permanent deletes of the same entrance could run interleaved. #1899 now runs the permanent delete in one transaction that locks the entrance row first (`SELECT … FOR UPDATE`), so the second request waits and then gets 404. This is what the issue asks for.

The existing concurrency test only covered a delete racing a merge, and its cave had no name. These tests cover the exact case from the issue: two plain deletes, with a name on the cave, so a regression gets caught.

The issue's open question was whether a `t_name` row can still reference the cave when the cave is destroyed, even without a race. It can't. `CaveService.permanentlyDeleteCave` runs `NameService.permanentDelete({ cave })` before the cave's hard delete, which removes every name with that `id_cave`, including one that also has `id_entrance`. The second new test checks this.

## 🔍 How

- The test database has no foreign keys, so `t_name_t_cave0_fk` can't fail there. Instead, the tests count the `t_name` rows still pointing at the cave or the entrance after the delete.
- I checked that the concurrent test catches the bug. With `api/controllers/v1/entrance/delete.js` and `api/services/CaveService.js` from before #1899, it fails w... (continued)

6362 of 7414 branches covered (85.81%)

Branch coverage included in aggregate %.

11693 of 12748 relevant lines covered (91.72%)

242761.27 hits per line