Files
TREK/server/tests/helpers/test-addons.ts
T
Maurice e015e5e5e8 fix(server): run the remaining multi-statement service writes in one transaction
A sweep of the services for write sequences that committed step by step,
each one leaving half a change behind when the next statement failed:

- accommodations: the linked bookings' times moved after the stay's own
  transaction had committed
- airports: the boot backfill wrote a flight's two endpoints one at a
  time, and a flight left with only the first was never picked up again;
  each flight is its own transaction now
- auth: the admin settings form and a password reset (retire the old
  link, issue the new one) each land whole
- oauth: a refresh revoked the old pair before issuing the new one, so a
  failure in between logged the client out; rotating a client secret and
  revoking its tokens go together too
- oidc: the identity link, the role from the claims and the avatar of a
  returning user are one write
- addons, notification preferences: a settings save lands whole
- places: create with its tags, update, and the GPX/KML imports with
  their track colours
- trips: the trip row, the shifted leave entries and the rebuilt day grid
- vacay: a first visit provisions the plan in one transaction with a
  second look against a concurrent first visit; updatePlan fetches the
  public holidays between two transactions instead of inside its writes
- memories: a photo and its trip link, and the deletes with the orphan
  sweep behind them

AddonsService, AirportsService and OauthService take the UnitOfWork for
this. Network I/O stays outside every transaction. Comments that only
narrated the migration plan make room under the lint:size entries, which
drop with them.
2026-10-08 18:41:32 +02:00

47 lines
2.2 KiB
TypeScript

import type Database from 'better-sqlite3';
import { AddonsService } from '../../src/nest/addons/addons.service';
import { sharedTestOrm } from './test-uow';
import { UnitOfWork } from '../../src/nest/database/unit-of-work';
import { Addons } from '../../src/db/entities/Addons.entity';
import { PhotoProviders } from '../../src/db/entities/PhotoProviders.entity';
import { PhotoProviderFields } from '../../src/db/entities/PhotoProviderFields.entity';
import { AppSettings } from '../../src/db/entities/AppSettings.entity';
import { Users } from '../../src/db/entities/Users.entity';
/**
* AddonsService's constructor grew from one `DatabaseService` to four
* injected repositories plus `DatabaseService` (Plan 3a Task 4, addons.md —
* the `AppSettingsRepository`/`AddonsRepository`/`PhotoProvidersRepository`/
* `PhotoProviderFieldsRepository` wiring). Every hand-constructed
* `new AddonsService(dbs)` in the test tree needs the same four repositories
* a real `@InjectRepository` graph would hand it — this file is that
* factory, named `test-addons.ts` per the Task 4 brief (owned by Task 4;
* `tests/helpers/test-uow.ts` stays Task 3's file to extend).
*
* Built on the shared per-handle ORM (`test-uow.ts`'s `sharedTestOrm`, not a
* fresh `createTestOrm` here) — the SAME one `createTestAppSettingsRepo`/
* `createTestUnitOfWork` draw from, so a repository built here and a
* `UnitOfWork`/repository built elsewhere for the same handle resolve
* through the identical context-resolving `EntityManager`, exactly like
* Nest's real DI graph (task-2-review.md I2's fix, carried forward for this
* domain).
*/
/**
* The full `AddonsService` a hand-constructed test collaborator needs, bound
* to the suite's own better-sqlite3 handle. Plan 4 Task 4 dropped the
* trailing `DatabaseService` param (dead in `AddonsService` itself since
* `transit-provider.ts`/`instance-api-keys.ts` moved onto
* `AppSettingsRepository` — Plan 4 Task 1).
*/
export async function createTestAddonsService(db: Database.Database): Promise<AddonsService> {
const t = await sharedTestOrm(db);
return new AddonsService(
t.repo(Addons),
t.repo(PhotoProviders),
t.repo(PhotoProviderFields),
t.repo(AppSettings),
t.repo(Users),
new UnitOfWork(t.em),
);
}