[Review] getIntimateSettings makes a redundant Dexie .get() call that won't match the indexed lookup — dead code path #187

New issue

Closed

opened 2026-09-14 14:07:30 +00:00 by Mark · 1 comment

Mark commented

2026-09-14 14:07:30 +00:00

Owner

Finding

src/vault/VaultStore.ts:469-475:

async getIntimateSettings(
  personId: number,
): Promise<VaultIntimateSettings | undefined> {
  this.assertUnlocked();
  return this.getDb().vaultIntimateSettings.get({ personId } as VaultIntimateSettings)
    ?? this.getDb().vaultIntimateSettings.where("personId").equals(personId).first();
}

Dexie's Table.get() takes a primary key (++id), not an indexed field. vaultIntimateSettings is declared at src/vault/vault-db.ts:146 with primary key ++id and a secondary index on personId. So .get({ personId }) will not match and returns undefined. The ?? then falls through to the proper where(...).first() lookup.

The first call is dead code. It still costs a Dexie round-trip on every call.

Suggested fix

Drop the first call:

async getIntimateSettings(
  personId: number,
): Promise<VaultIntimateSettings | undefined> {
  this.assertUnlocked();
  return this.getDb().vaultIntimateSettings.where("personId").equals(personId).first();
}

Add a comment that explains why where().first() is used (the schema has ++id as primary key, so .get() requires the integer id).

Severity

Trivial. Dead code, minor perf cost.

Discovered by

Manual code review pass over #169, 2026-09-14.

## Finding `src/vault/VaultStore.ts:469-475`: ```ts async getIntimateSettings( personId: number, ): Promise<VaultIntimateSettings | undefined> { this.assertUnlocked(); return this.getDb().vaultIntimateSettings.get({ personId } as VaultIntimateSettings) ?? this.getDb().vaultIntimateSettings.where("personId").equals(personId).first(); } ``` Dexie's `Table.get()` takes a primary key (`++id`), not an indexed field. `vaultIntimateSettings` is declared at `src/vault/vault-db.ts:146` with primary key `++id` and a secondary index on `personId`. So `.get({ personId })` will not match and returns `undefined`. The `??` then falls through to the proper `where(...).first()` lookup. The first call is dead code. It still costs a Dexie round-trip on every call. ## Suggested fix Drop the first call: ```ts async getIntimateSettings( personId: number, ): Promise<VaultIntimateSettings | undefined> { this.assertUnlocked(); return this.getDb().vaultIntimateSettings.where("personId").equals(personId).first(); } ``` Add a comment that explains why `where().first()` is used (the schema has `++id` as primary key, so `.get()` requires the integer id). ## Severity Trivial. Dead code, minor perf cost. ## Discovered by Manual code review pass over #169, 2026-09-14.

Mark commented

2026-09-14 14:46:38 +00:00

Author

Owner

Closed by watcher after partial-success recovery.

The fix landed on origin/main as commit cdeef64 (blob be49614 on src/vault/VaultStore.ts). The kilo-gsd runner for #187 produced the same diff on a parallel worktree and the push-failed recovery was caught by the watcher because the local HEAD diverged from origin/main by one commit (cdeef64 — a squash from the #186 worker that captured this fix's worktree state).

Substance: the redundant Table.get({ personId }) call in getIntimateSettings is gone; the function now goes straight to where('personId').equals(personId).first() which is the only lookup that actually matches against the indexed ++id Dexie PK.

Resolves Mark/kimi_agent_kin_app_sync#187

Closed by watcher after partial-success recovery. The fix landed on `origin/main` as commit `cdeef64` (blob `be49614` on `src/vault/VaultStore.ts`). The kilo-gsd runner for #187 produced the same diff on a parallel worktree and the push-failed recovery was caught by the watcher because the local HEAD diverged from origin/main by one commit (`cdeef64` — a squash from the #186 worker that captured this fix's worktree state). Substance: the redundant `Table.get({ personId })` call in `getIntimateSettings` is gone; the function now goes straight to `where('personId').equals(personId).first()` which is the only lookup that actually matches against the indexed `++id` Dexie PK. Resolves Mark/kimi_agent_kin_app_sync#187

Mark closed this issue

2026-09-14 14:46:38 +00:00

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

Mark/kimi_agent_kin_app_sync#187

No description provided.

Rows
Columns