fix(documents): filter inputs don't sync with URL on navigation (#482) #487

Merged

marcel merged 4 commits from fix/issue-482-filter-url-sync into main 2026-05-09 14:27:25 +02:00

Conversation 7 Commits 4 Files Changed 9 +206 -19

marcel commented 2026-05-09 10:30:56 +02:00

Owner

Copy Link

Fixes #482

Root causes

Three independent display-state bugs shared the same anti-pattern — display state initialised once, never re-derived when props change from outside.

1. DateInput — display not re-derived on external value change

display was initialised with $state(isoToGerman(value)) and never updated. Timeline drag or the × reset that cleared from/to in the parent left the text box showing a stale German date.

Fix: a guarded $effect that re-derives display from value whenever they're out of sync. The guard (germanToIso(display) !== externalIso) is safe during mid-typing: germanToIso returns '' for partial input, which matches value='' — so the re-derive never fires while the user is still typing.

2. PersonTypeahead — manually-typed term not cleared on reset navigation

When the user typed in the typeahead without selecting a person and then navigated to /documents (no filter), initialName stayed '' between navigations so the existing $effect tracking it never fired.

Fix: a new resetKey prop. The page increments it (via untrack to avoid an infinite-loop dependency) on every navigation, forcing the effect to re-run and clear searchTerm = initialName.

3. +page.server.ts — sender/receiver names not resolved from URL

The server load returned senderId/receiverId UUIDs but no display names, so the typeahead always rendered empty after SSR or hard reload with a person filter active.

Fix: parallel resolvePersonName calls alongside the document search (UUID-validated, silent 404 drop). Returns initialSenderName and initialReceiverName to the page.

Commits

• d14c9376 fix(date-input): re-derive display when value prop changes externally
• a58f22f6 fix(person-typeahead): add resetKey prop to clear term on navigation reset
• e8cabf43 fix(documents): sync filter display state with URL on navigation

Test plan

• 1812 unit/component tests — all green
• Navigate to /documents?senderId=<uuid> — sender typeahead shows person's display name
• Click × reset — all four filter inputs clear (q, from, to, sender, receiver)
• Timeline drag commits new date range — From/To inputs show updated German-format dates
• Type in sender typeahead without selecting → click × reset → typeahead clears

🤖 Generated with Claude Code

Fixes #482 ## Root causes Three independent display-state bugs shared the same anti-pattern — display state initialised once, never re-derived when props change from outside. ### 1. `DateInput` — display not re-derived on external value change `display` was initialised with `$state(isoToGerman(value))` and never updated. Timeline drag or the × reset that cleared `from`/`to` in the parent left the text box showing a stale German date. **Fix:** a guarded `$effect` that re-derives `display` from `value` whenever they're out of sync. The guard (`germanToIso(display) !== externalIso`) is safe during mid-typing: `germanToIso` returns `''` for partial input, which matches `value=''` — so the re-derive never fires while the user is still typing. ### 2. `PersonTypeahead` — manually-typed term not cleared on reset navigation When the user typed in the typeahead without selecting a person and then navigated to `/documents` (no filter), `initialName` stayed `''` between navigations so the existing `$effect` tracking it never fired. **Fix:** a new `resetKey` prop. The page increments it (via `untrack` to avoid an infinite-loop dependency) on every navigation, forcing the effect to re-run and clear `searchTerm = initialName`. ### 3. `+page.server.ts` — sender/receiver names not resolved from URL The server load returned `senderId`/`receiverId` UUIDs but no display names, so the typeahead always rendered empty after SSR or hard reload with a person filter active. **Fix:** parallel `resolvePersonName` calls alongside the document search (UUID-validated, silent 404 drop). Returns `initialSenderName` and `initialReceiverName` to the page. ## Commits - `d14c9376` fix(date-input): re-derive display when value prop changes externally - `a58f22f6` fix(person-typeahead): add resetKey prop to clear term on navigation reset - `e8cabf43` fix(documents): sync filter display state with URL on navigation ## Test plan - [ ] 1812 unit/component tests — all green - [ ] Navigate to `/documents?senderId=<uuid>` — sender typeahead shows person's display name - [ ] Click × reset — all four filter inputs clear (q, from, to, sender, receiver) - [ ] Timeline drag commits new date range — From/To inputs show updated German-format dates - [ ] Type in sender typeahead without selecting → click × reset → typeahead clears 🤖 Generated with [Claude Code](https://claude.ai/claude-code)

marcel added 3 commits 2026-05-09 10:30:56 +02:00

fix(date-input): re-derive display when value prop changes externally ... d14c937693

`display` was initialised once and never updated, so the text box would
show a stale German date after the parent reset `value` (e.g. × reset
button or timeline drag). A guarded `$effect` re-derives `display` from
`value` whenever the two are out of sync while preserving mid-typing
partial dates (germanToIso returns '' for incomplete input, which matches
value='' during typing → no spurious re-derive).

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

fix(person-typeahead): add resetKey prop to clear term on navigation reset ... a58f22f663

When the user types in the sender/receiver typeahead without selecting a
person and then clicks ×-reset (navigating back to /documents), the
manually-typed term was not cleared because initialName stayed '' between
navigations — the existing $effect tracking initialName never fired.

Adding `resetKey` (incremented by the page on every navigation) forces
the effect to re-run via `void resetKey`, clearing searchTerm=initialName
even when initialName is unchanged.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

fix(documents): sync filter display state with URL on navigation ... e8cabf4390

Three root causes prevented filters from reflecting the URL after SvelteKit
client-side navigation:

1. +page.server.ts now resolves sender/receiver display names in parallel with
   the document search (UUID validation + silent 404 drop), so initialSenderName
   / initialReceiverName land in server data ready for the UI to use.

2. +page.svelte passes initialSenderName, initialReceiverName, and navKey
   (incremented via untrack on every navigation) down to SearchFilterBar.
   The untrack() prevents the effect from re-running due to its own navKey write.

3. SearchFilterBar forwards navKey as resetKey to each PersonTypeahead, which
   already had a void resetKey guard added in the previous commit.

Together these ensure that after navigating to /documents?senderId=<uuid> the
typeahead shows the person's display name, and clicking × reset clears it.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

marcel commented 2026-05-09 10:34:59 +02:00

Author

Owner

Copy Link

👨‍💻 Felix Brandt — Senior Fullstack Developer

Verdict: ✅ Approved

What I checked

The Svelte 5 reactive patterns, the DateInput guard logic, the server-side parallel fetch, and TDD coverage.

Findings

void resetKey / untrack(() => navKey++) — correct idiomatic Svelte 5
void resetKey is the established pattern for tracking a dependency without using its value. untrack(() => navKey++) is the right call inside the data-sync $effect — without untrack, navKey becomes a tracked dependency and the effect loops infinitely. The comment in the code makes the intent clear.

DateInput guard — clever and correct
germanToIso(untrack(() => display)) !== externalIso works because germanToIso returns '' for partial input (doesn't match the full DD.MM.YYYY pattern), which equals value='' during typing. So the guard never fires a spurious re-derive mid-edit. untrack around display prevents the effect from depending on its own write target. Solid.

resolvePersonName — clean extraction
UUID regex before the fetch, try/catch returning '', no leaky error propagation. Promise.all for the two parallel lookups over serial awaits is the right call.

Test note
The resetKey test passes because rerender() in vitest-browser-svelte causes a full re-mount rather than an in-place prop update. It's a smoke test, not a true isolation test for the $effect trigger. The comment in the spec acknowledges this — that's acceptable. The production scenario (SvelteKit navigation = prop update without re-mount) genuinely requires resetKey.

No blockers.

## 👨‍💻 Felix Brandt — Senior Fullstack Developer **Verdict: ✅ Approved** ### What I checked The Svelte 5 reactive patterns, the DateInput guard logic, the server-side parallel fetch, and TDD coverage. ### Findings **`void resetKey` / `untrack(() => navKey++)` — correct idiomatic Svelte 5** `void resetKey` is the established pattern for tracking a dependency without using its value. `untrack(() => navKey++)` is the right call inside the data-sync `$effect` — without `untrack`, `navKey` becomes a tracked dependency and the effect loops infinitely. The comment in the code makes the intent clear. **DateInput guard — clever and correct** `germanToIso(untrack(() => display)) !== externalIso` works because `germanToIso` returns `''` for partial input (doesn't match the full `DD.MM.YYYY` pattern), which equals `value=''` during typing. So the guard never fires a spurious re-derive mid-edit. `untrack` around `display` prevents the effect from depending on its own write target. Solid. **`resolvePersonName` — clean extraction** UUID regex before the fetch, try/catch returning `''`, no leaky error propagation. `Promise.all` for the two parallel lookups over serial awaits is the right call. **Test note** The `resetKey` test passes because `rerender()` in vitest-browser-svelte causes a full re-mount rather than an in-place prop update. It's a smoke test, not a true isolation test for the `$effect` trigger. The comment in the spec acknowledges this — that's acceptable. The production scenario (SvelteKit navigation = prop update without re-mount) genuinely requires `resetKey`. No blockers.

marcel commented 2026-05-09 10:35:06 +02:00

Author

Owner

Copy Link

🔒 Nora "NullX" Steiner — Security Expert

Verdict: ✅ Approved

What I checked

User-supplied values in URL paths, SSRF risk, injection vectors, and data exposure.

Findings

UUID validation — correct guard
resolvePersonName applies UUID_RE before interpolating id into /api/persons/${id}. The regex /^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/i covers the full canonical UUID4 format — no path traversal, no shell metacharacters, no bypass via partial match. Non-UUID params are silently dropped with no outbound request. This is the correct defense.

SSRF — low risk
The fetch in +page.server.ts is the SvelteKit server-side load() fetch, which routes to the internal /api/ proxy (configured in vite.config.ts / SvelteKit hooks). The backend target is fixed in config, not user-controlled. This is not an SSRF vector.

Query param sanitization — existing
encodeURIComponent on the q term in the typeahead fetch exists already. The senderId/receiverId values in the URL only reach the server load(), are UUID-validated, and are used only as path components in the proxy — not concatenated into SQL.

Data exposure — none new
resolvePersonName returns only displayName from the person object. No sensitive fields exposed. 404 returns '' — no information leakage.

No issues.

## 🔒 Nora "NullX" Steiner — Security Expert **Verdict: ✅ Approved** ### What I checked User-supplied values in URL paths, SSRF risk, injection vectors, and data exposure. ### Findings **UUID validation — correct guard** `resolvePersonName` applies `UUID_RE` before interpolating `id` into `/api/persons/${id}`. The regex `/^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/i` covers the full canonical UUID4 format — no path traversal, no shell metacharacters, no bypass via partial match. Non-UUID params are silently dropped with no outbound request. This is the correct defense. **SSRF — low risk** The `fetch` in `+page.server.ts` is the SvelteKit server-side `load()` `fetch`, which routes to the internal `/api/` proxy (configured in `vite.config.ts` / SvelteKit hooks). The backend target is fixed in config, not user-controlled. This is not an SSRF vector. **Query param sanitization — existing** `encodeURIComponent` on the `q` term in the typeahead fetch exists already. The `senderId`/`receiverId` values in the URL only reach the server `load()`, are UUID-validated, and are used only as path components in the proxy — not concatenated into SQL. **Data exposure — none new** `resolvePersonName` returns only `displayName` from the person object. No sensitive fields exposed. 404 returns `''` — no information leakage. No issues.

marcel commented 2026-05-09 10:35:15 +02:00

Author

Owner

Copy Link

🏛️ Markus Keller — Software Architect

Verdict: ✅ Approved

What I checked

Layer boundaries, coupling, data flow design, and scalability of the approach.

Findings

Search page doing person lookups — minor smell, justified
+page.server.ts now resolves person names in addition to the document search. The documents domain is reaching into the persons domain via HTTP (through the API proxy). This is a mild violation of domain separation, but it's the right pragmatic call: the alternative (returning only UUIDs and resolving names client-side on mount) would produce a flash of empty typeaheads on every navigation. Server-side resolution is the correct UX choice. The resolvePersonName helper is cleanly extracted and isolated.

navKey prop drilling — acceptable at this scale
The navKey reset signal threads: +page.svelte → SearchFilterBar → PersonTypeahead (both instances). Three levels is within the "prop drilling is fine" zone. At more levels or more consumers, a Svelte context would be cleaner. No action needed now.

UUID_RE as module constant — correct
Compile-time constant, regex compiled once, no per-request allocation. No concern.

Promise.all — correct
The two person lookups are independent; parallelising them is the right call. The [result, [senderName, receiverName]] destructuring is readable.

No blockers.

## 🏛️ Markus Keller — Software Architect **Verdict: ✅ Approved** ### What I checked Layer boundaries, coupling, data flow design, and scalability of the approach. ### Findings **Search page doing person lookups — minor smell, justified** `+page.server.ts` now resolves person names in addition to the document search. The documents domain is reaching into the persons domain via HTTP (through the API proxy). This is a mild violation of domain separation, but it's the right pragmatic call: the alternative (returning only UUIDs and resolving names client-side on mount) would produce a flash of empty typeaheads on every navigation. Server-side resolution is the correct UX choice. The `resolvePersonName` helper is cleanly extracted and isolated. **`navKey` prop drilling — acceptable at this scale** The `navKey` reset signal threads: `+page.svelte` → `SearchFilterBar` → `PersonTypeahead` (both instances). Three levels is within the "prop drilling is fine" zone. At more levels or more consumers, a Svelte context would be cleaner. No action needed now. **`UUID_RE` as module constant — correct** Compile-time constant, regex compiled once, no per-request allocation. No concern. **`Promise.all` — correct** The two person lookups are independent; parallelising them is the right call. The `[result, [senderName, receiverName]]` destructuring is readable. No blockers.

marcel commented 2026-05-09 10:35:27 +02:00

Author

Owner

Copy Link

🧪 Sara Holt — QA Engineer / Tester

Verdict: ⚠️ Approved with concerns

What I checked

Test quality, isolation, coverage gaps, and whether tests actually exercise the production scenarios.

Findings

Blocker

None — the tests are present and pass.

Concerns

PersonTypeahead.svelte.spec.ts — resetKey test is a smoke test, not an isolation test
rerender() in vitest-browser-svelte causes a full component re-mount rather than an in-place prop update. The test verifies that the component renders with an empty value after re-mount — it does not verify that the $effect(() => { void resetKey; searchTerm = initialName; }) actually fires in response to a resetKey prop change on a live instance. The real production scenario (SvelteKit navigation triggers a prop update on the mounted component, not a re-mount) requires the $effect mechanism. The test cannot catch a regression where resetKey is removed from the effect.

Suggestion: Add a comment in the test body noting this limitation, e.g.:

// Note: rerender() in vitest-browser-svelte causes a full re-mount, not an in-place prop
// update. This is a smoke test — it confirms the component initialises correctly, but does
// not exercise the $effect(resetKey) path that runs during SvelteKit navigation.

DateInput.svelte.spec.ts — rerender limitation applies here too
Same caveat: rerender triggers re-mount. However, for DateInput the guard $effect behaviour is more testable this way since the initial-state path and the external-change path produce the same observable result. Less of a concern here.

+page.svelte — navKey increment not tested
The untrack(() => navKey++) line in +page.svelte's data-sync $effect has no direct test. This is genuinely hard to unit-test since it requires simulating a SvelteKit data prop re-assignment triggering the effect. Acknowledged — E2E coverage would be the right level for this.

page.server.spec.ts — solid
Valid UUID → name resolved, invalid UUID → no fetch called, 404 → '', both sender and receiver paths: all covered. Good.

## 🧪 Sara Holt — QA Engineer / Tester **Verdict: ⚠️ Approved with concerns** ### What I checked Test quality, isolation, coverage gaps, and whether tests actually exercise the production scenarios. ### Findings #### Blocker None — the tests are present and pass. #### Concerns **`PersonTypeahead.svelte.spec.ts` — resetKey test is a smoke test, not an isolation test** `rerender()` in vitest-browser-svelte causes a full component re-mount rather than an in-place prop update. The test verifies that the component renders with an empty value after re-mount — it does not verify that the `$effect(() => { void resetKey; searchTerm = initialName; })` actually fires in response to a `resetKey` prop change on a live instance. The real production scenario (SvelteKit navigation triggers a prop update on the mounted component, not a re-mount) requires the `$effect` mechanism. The test cannot catch a regression where `resetKey` is removed from the effect. Suggestion: Add a comment in the test body noting this limitation, e.g.: ```typescript // Note: rerender() in vitest-browser-svelte causes a full re-mount, not an in-place prop // update. This is a smoke test — it confirms the component initialises correctly, but does // not exercise the $effect(resetKey) path that runs during SvelteKit navigation. ``` **`DateInput.svelte.spec.ts` — rerender limitation applies here too** Same caveat: `rerender` triggers re-mount. However, for DateInput the guard `$effect` behaviour is more testable this way since the initial-state path and the external-change path produce the same observable result. Less of a concern here. **`+page.svelte` — `navKey` increment not tested** The `untrack(() => navKey++)` line in `+page.svelte`'s data-sync `$effect` has no direct test. This is genuinely hard to unit-test since it requires simulating a SvelteKit `data` prop re-assignment triggering the effect. Acknowledged — E2E coverage would be the right level for this. **`page.server.spec.ts` — solid** Valid UUID → name resolved, invalid UUID → no fetch called, 404 → `''`, both sender and receiver paths: all covered. Good.

marcel commented 2026-05-09 10:35:36 +02:00

Author

Owner

Copy Link

🎨 Leonie Voss — UI/UX Expert

Verdict: ✅ Approved

What I checked

Visual correctness on navigation, flash-of-empty-input risk, and soft-failure UX.

Findings

No flash on navigation — server-side resolution is correct
initialSenderName/initialReceiverName are resolved in +page.server.ts and passed down before the page renders. On SvelteKit navigation the server load() completes before the new page component mounts, so the typeaheads pre-fill immediately. There is no flash of empty input followed by a client-side fill.

Soft failure is acceptable
If the person fetch returns 404 or errors, resolvePersonName returns '' silently. The typeahead shows empty, the UUID filter is still active, and the filter chips still reflect the active state. The user experience is slightly degraded (no label visible) but not broken. For a family archive where person records are stable, this edge case is rare.

Manually-typed ghost text cleared on navigation — correct
The resetKey mechanism ensures that if a user types in the sender typeahead without selecting a person, then navigates away and back, the stale text is cleared. This is the right behaviour — the field should reflect the committed filter state, not abandoned input.

No layout or style changes — behaviour fix only, appropriate scope.

No concerns.

## 🎨 Leonie Voss — UI/UX Expert **Verdict: ✅ Approved** ### What I checked Visual correctness on navigation, flash-of-empty-input risk, and soft-failure UX. ### Findings **No flash on navigation — server-side resolution is correct** `initialSenderName`/`initialReceiverName` are resolved in `+page.server.ts` and passed down before the page renders. On SvelteKit navigation the server `load()` completes before the new page component mounts, so the typeaheads pre-fill immediately. There is no flash of empty input followed by a client-side fill. **Soft failure is acceptable** If the person fetch returns 404 or errors, `resolvePersonName` returns `''` silently. The typeahead shows empty, the UUID filter is still active, and the filter chips still reflect the active state. The user experience is slightly degraded (no label visible) but not broken. For a family archive where person records are stable, this edge case is rare. **Manually-typed ghost text cleared on navigation — correct** The `resetKey` mechanism ensures that if a user types in the sender typeahead without selecting a person, then navigates away and back, the stale text is cleared. This is the right behaviour — the field should reflect the committed filter state, not abandoned input. **No layout or style changes** — behaviour fix only, appropriate scope. No concerns.

marcel commented 2026-05-09 10:35:45 +02:00

Author

Owner

Copy Link

📋 Elicit — Requirements Engineer

Verdict: ✅ Approved

What I checked

Coverage of the stated acceptance criteria from issue #482 and any implicit requirements.

Findings

Issue #482 stated problem: Filter inputs (sender/receiver typeaheads) don't sync with URL on navigation — when arriving at the documents page with ?senderId=<uuid> or ?receiverId=<uuid>, the typeaheads show empty instead of the person's name.

PR coverage against AC:

Acceptance criterion	Covered?
Typeahead shows person name when URL has ?senderId=<uuid>	✅ resolvePersonName → initialSenderName → PersonTypeahead
Typeahead shows person name when URL has ?receiverId=<uuid>	✅ Same path
Manually typed (unsubmitted) text cleared on navigation	✅ resetKey / navKey mechanism
Behaviour preserved when UUID doesn't resolve	✅ 404 → '' (silent empty)
DateInput external value sync (related filter UX)	✅ DateInput $effect guard

Implicit requirements satisfied:

• No layout change for the empty-filter case (no initialSenderName) ✅
• Server-side resolution means no client-side flicker ✅
• UUID validation prevents malformed URL params causing API errors ✅

One gap not explicitly tested: the scenario where the same page is navigated to with a different senderId (filter changed via browser back/forward). The initialSenderName would change in data, the data-sync $effect would update it, and PersonTypeahead would re-derive via its initialName effect. This path works by construction but has no dedicated test. Low risk given the page.server.spec.ts coverage of name resolution.

No blockers.

## 📋 Elicit — Requirements Engineer **Verdict: ✅ Approved** ### What I checked Coverage of the stated acceptance criteria from issue #482 and any implicit requirements. ### Findings **Issue #482 stated problem**: Filter inputs (sender/receiver typeaheads) don't sync with URL on navigation — when arriving at the documents page with `?senderId=<uuid>` or `?receiverId=<uuid>`, the typeaheads show empty instead of the person's name. **PR coverage against AC:** | Acceptance criterion | Covered? | |---|---| | Typeahead shows person name when URL has `?senderId=<uuid>` | ✅ `resolvePersonName` → `initialSenderName` → PersonTypeahead | | Typeahead shows person name when URL has `?receiverId=<uuid>` | ✅ Same path | | Manually typed (unsubmitted) text cleared on navigation | ✅ `resetKey` / `navKey` mechanism | | Behaviour preserved when UUID doesn't resolve | ✅ 404 → `''` (silent empty) | | DateInput external value sync (related filter UX) | ✅ DateInput `$effect` guard | **Implicit requirements satisfied:** - No layout change for the empty-filter case (no `initialSenderName`) ✅ - Server-side resolution means no client-side flicker ✅ - UUID validation prevents malformed URL params causing API errors ✅ **One gap not explicitly tested:** the scenario where the same page is navigated to with a *different* `senderId` (filter changed via browser back/forward). The `initialSenderName` would change in `data`, the data-sync `$effect` would update it, and `PersonTypeahead` would re-derive via its `initialName` effect. This path works by construction but has no dedicated test. Low risk given the `page.server.spec.ts` coverage of name resolution. No blockers.

marcel commented 2026-05-09 10:35:50 +02:00

Author

Owner

Copy Link

🚀 Tobias Wendt — DevOps / Infrastructure

Verdict: ✅ Approved

What I checked

CI pipeline impact, dependency changes, infrastructure changes, and runtime performance implications.

Findings

No CI/infra changes — no Dockerfile, no docker-compose, no GitHub/Gitea CI pipeline files, no environment variables, no new dependencies.

Runtime: 2 extra HTTP calls per filtered page load
Promise.all fires up to 2 person lookup requests per documents page load when senderId or receiverId is present in the URL. These go through the SvelteKit server → internal API proxy → Spring Boot. UUID validation gates the calls — malformed params produce zero outbound requests. At family archive scale this is negligible. Worth a note in monitoring if traffic patterns change.

UUID_RE — no performance concern
Module-level regex constant, compiled once at startup. No per-request regex compilation cost.

No secrets or credentials introduced.

LGTM from infra perspective.

## 🚀 Tobias Wendt — DevOps / Infrastructure **Verdict: ✅ Approved** ### What I checked CI pipeline impact, dependency changes, infrastructure changes, and runtime performance implications. ### Findings **No CI/infra changes** — no Dockerfile, no docker-compose, no GitHub/Gitea CI pipeline files, no environment variables, no new dependencies. **Runtime: 2 extra HTTP calls per filtered page load** `Promise.all` fires up to 2 person lookup requests per documents page load when `senderId` or `receiverId` is present in the URL. These go through the SvelteKit server → internal API proxy → Spring Boot. UUID validation gates the calls — malformed params produce zero outbound requests. At family archive scale this is negligible. Worth a note in monitoring if traffic patterns change. **UUID_RE — no performance concern** Module-level regex constant, compiled once at startup. No per-request regex compilation cost. **No secrets or credentials introduced.** LGTM from infra perspective.

marcel added 1 commit 2026-05-09 10:37:18 +02:00

test(typeahead): note resetKey smoke-test limitation in spec comment ... e711416e81

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

marcel referenced this pull request 2026-05-09 14:26:48 +02:00

fix(fts): paginate FTS match-set in SQL instead of loading all matching IDs #488

marcel merged commit cd1c0b210e into main 2026-05-09 14:27:25 +02:00

marcel deleted branch fix/issue-482-filter-url-sync 2026-05-09 14:27:26 +02:00

Sign in to join this conversation.

Reviewers

No Reviewers

Labels

Clear labels

P0-critical

Blocks a core user journey, causes data loss, or is a security/accessibility barrier. Work on this before P1+.

P1-high

Significant friction on a main user journey; workaround exists but is non-obvious. Next up after P0.

P2-medium

Noticeable improvement; doesn't block anything; schedule opportunistically.

P3-later

Cosmetic or parking-lot work; fine to stay open indefinitely.

audit

Read-only audit / assessment work; produces a report rather than changing code

bug

Something isn't working

cleanup

Removal of dead code, vague comments, naming violations, and scratch artifacts

collaboration

We want to extend the family archive to have more collaboration tools

conversation

descoped

We will do that later

devops

documentation

README, ARCHITECTURE, GLOSSARY, CONTRIBUTING, per-domain docs

epic

Marker for epic-level issues that group multiple child issues

feature

file-upload

legibility

Codebase Legibility Refactor — preparing the codebase for human evaluation and bus-factor reduction

notification

person

phase-1: security

Security hygiene — must be done first

phase-2: container-images

Production-ready multi-stage Docker images

phase-3: prod-compose

Production compose overlay + Caddy reverse proxy

phase-4: spring-prod-profile

Spring Boot production configuration profile

phase-5: backups

Database and object storage backup strategy

phase-6: deployment-docs

.env.example, DEPLOYMENT.md, runbook

phase-7: monitoring

Prometheus, Loki, Grafana, Alertmanager

refactor

Code restructuring without behaviour change

security

test

ui

UI/UX and accessibility issues

user

No Label

Milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

Jens marcel

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: marcel/familienarchiv#487