Bernd RodlerandClaude Sonnet 5
bde8455df5
QA pass on the encrypted mail index found two real gaps beyond what the
prior end-to-end fix pass caught:
1. store.ts's MailIndex.open() only wrapped SOME of the post-key pragma
calls in a try/catch before this: the first attempt's `key` pragma and
assertEncrypted() ran outside any try at all, and the wrong-key retry
repeated the same gap. Any pragma throwing there (SQLITE_BUSY, a full
disk on the first WAL write) leaked the native SQLite handle instead of
closing it. Factored the open+key+verify+pragma sequence into openKeyed(),
which guarantees a close before rethrowing on any failure, and reused it
for both the first attempt and the retry.
2. reindex.ts never removed a deleted contact or file from the index. The
`removed` field exists in the API and is fully tested at the store layer,
but nothing in the renderer populates it, so a deleted contact/file stayed
searchable - and retrievable by the AI feature - indefinitely. Mail and
calendar can't use the same fix (their queries are date-windowed, so an id
missing from one fetch may just be outside the window), but contacts/files
have no date filter - a catch-up fetch that comes back under its cap IS
the complete set, so anything locally indexed but absent from it is safely
known to be deleted. Added strayIdsAfterCatchUp() and wired it into the
catch-up path for those two types only.
Also read binding.ts, key.ts, paths.ts, jmap.ts, extract.ts, the FTS5
query builder, and both /api/offline/{search,reindex} routes end to end;
no other concrete bugs found there. Full findings reported separately.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
32 lines
1.5 KiB
TypeScript
32 lines
1.5 KiB
TypeScript
import { describe, expect, it } from 'vitest';
|
|
import { strayIdsAfterCatchUp } from '../reindex';
|
|
|
|
describe('strayIdsAfterCatchUp', () => {
|
|
it('removes locally-indexed ids absent from a complete (uncapped) fetch', () => {
|
|
// Contacts/files have no date filter, so a catch-up query that comes back
|
|
// under the cap IS the whole account - anything indexed but missing from
|
|
// it was deleted. This is the only place a JMAP `destroyed` ever reaches
|
|
// these two content types, since nothing in the renderer populates
|
|
// reindex's `removed` field.
|
|
const existing = new Set(['a', 'b', 'c']);
|
|
expect(strayIdsAfterCatchUp(existing, ['a', 'c'], 2, 2_000)).toEqual(['b']);
|
|
});
|
|
|
|
it('does nothing when the fetch is empty but so is the local index', () => {
|
|
expect(strayIdsAfterCatchUp(new Set(), [], 0, 2_000)).toEqual([]);
|
|
});
|
|
|
|
it('never removes anything when the query hit its cap - a truncated page is not the whole world', () => {
|
|
// Exactly the case that would otherwise delete objects that are still
|
|
// live: an account with >= cap contacts/files, where "missing from this
|
|
// page" only means "not on this page", not "gone".
|
|
const existing = new Set(['a', 'b', 'c']);
|
|
expect(strayIdsAfterCatchUp(existing, ['a'], 2_000, 2_000)).toEqual([]);
|
|
});
|
|
|
|
it('is a no-op when nothing is stray', () => {
|
|
const existing = new Set(['a', 'b']);
|
|
expect(strayIdsAfterCatchUp(existing, ['a', 'b', 'c'], 3, 2_000)).toEqual([]);
|
|
});
|
|
});
|