marcel/familienarchiv
1
0
Fork 0
Code Issues 119 Pull Requests 2 Actions Packages Projects Releases Wiki Activity

fix: reconcile JourneyItem note maxlength — frontend caps at 2000, backend accepts 5000 #793

New Issue
Open
opened 2026-06-09 16:17:51 +02:00 by marcel · 0 comments
marcel commented 2026-06-09 16:17:51 +02:00
Owner
Copy Link

Problem

JourneyItemRow.svelte enforces maxlength="2000" on the note textarea, matching the spec. But the backend constant JourneyItemService.MAX_NOTE_LENGTH is set to 5000 characters — no @Size or @Valid constraint enforces this at the HTTP boundary.

This creates an inconsistent contract:

  • Notes saved via the JourneyEditor UI are capped at 2000 chars.
  • Notes saved via a direct PATCH /api/geschichten/{id}/items/{itemId} API call can be up to 5000 chars.
  • If a 4000-char note is saved via the API, the JourneyItemRow textarea's bind:value will load all 4000 chars — but the maxlength="2000" attribute silently prevents the user from editing beyond that point, and a blur-triggered onNotePatch call would truncate the content.

Decision needed

One of these must be chosen before this stays in production:

  • Option A (raise frontend): Update maxlength to 5000 in JourneyItemRow.svelte and the spec. The backend is the source of truth.
  • Option B (lower backend): Add a @Size(max = 2000) validation to the PATCH DTO and update MAX_NOTE_LENGTH to 2000. The spec is the source of truth.

Acceptance criteria

  • maxlength in JourneyItemRow.svelte matches the backend constraint
  • Backend returns a JOURNEY_NOTE_TOO_LONG error (400) when the limit is exceeded via API — regardless of the chosen limit
  • Spec HTML updated to match the resolved limit
  • No silent truncation is possible: API and UI enforce the same cap

Context

Surfaced during PR review of #792 (JourneyEditor frontend). The PR description acknowledges the discrepancy; this issue tracks the resolution.

## Problem `JourneyItemRow.svelte` enforces `maxlength="2000"` on the note textarea, matching the spec. But the backend constant `JourneyItemService.MAX_NOTE_LENGTH` is set to **5000** characters — no `@Size` or `@Valid` constraint enforces this at the HTTP boundary. This creates an inconsistent contract: - Notes saved via the `JourneyEditor` UI are capped at 2000 chars. - Notes saved via a direct `PATCH /api/geschichten/{id}/items/{itemId}` API call can be up to 5000 chars. - If a 4000-char note is saved via the API, the `JourneyItemRow` textarea's `bind:value` will load all 4000 chars — but the `maxlength="2000"` attribute silently prevents the user from editing beyond that point, and a blur-triggered `onNotePatch` call would truncate the content. ## Decision needed One of these must be chosen before this stays in production: - **Option A (raise frontend):** Update `maxlength` to `5000` in `JourneyItemRow.svelte` and the spec. The backend is the source of truth. - **Option B (lower backend):** Add a `@Size(max = 2000)` validation to the PATCH DTO and update `MAX_NOTE_LENGTH` to 2000. The spec is the source of truth. ## Acceptance criteria - [ ] `maxlength` in `JourneyItemRow.svelte` matches the backend constraint - [ ] Backend returns a `JOURNEY_NOTE_TOO_LONG` error (`400`) when the limit is exceeded via API — regardless of the chosen limit - [ ] Spec HTML updated to match the resolved limit - [ ] No silent truncation is possible: API and UI enforce the same cap ## Context Surfaced during PR review of #792 (JourneyEditor frontend). The PR description acknowledges the discrepancy; this issue tracks the resolution.
marcel added the P1-highbug labels 2026-06-09 16:17:54 +02:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
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
 needs-discussion
Has an open decision or design question that must be resolved before implementation can start.
 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 P1-high bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
Jens marcel
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: marcel/familienarchiv#793
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?