fix(dashboard): truncate subject to the schema's 300-char limit

logWorkAction wrote the full polished/typed message into both `summary`
and `subject`, but `subject` exists to hold a short git commit subject
line and is capped at 300 characters at the schema level. Any note over
300 characters (trivially reachable — a 2-3 sentence polished note
routinely runs 350-450 characters) failed the create call outright, and
the generic catch surfaced only "Could not save that entry" with the
real reason discoverable only by reproducing the write directly against
PocketBase.

`subject` is only ever a fallback for when `summary` is empty
(`commit.summary || commit.subject`), and a logged entry's summary is
always populated at creation — so truncating subject costs nothing
functionally. Also logs the underlying error server-side on any future
create failure, so this class of bug doesn't require re-deriving the
cause from scratch again.

Reproduced against the live PocketBase instance with the exact message
that failed for the user (348 chars) before and after the fix.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
Dave 2026-09-19 14:49:39 +02:00
parent 990de29683
commit 9ddf8571f6

View file

@ -100,7 +100,12 @@ export async function logWorkAction(input: {
sha: `manual-${randomUUID()}`,
short_sha: "manual",
message,
subject: message,
// subject has a 300-character limit at the schema level (it exists to
// hold a short git commit subject line). A logged entry's summary is
// always populated, so subject here is only ever a fallback that will
// in practice never be read — but it is still validated on write, so
// it must be truncated to fit rather than holding the full message.
subject: message.slice(0, 300),
type: "",
scope: "",
author_name: "",
@ -124,7 +129,13 @@ export async function logWorkAction(input: {
source: "manual",
manual_minutes: Math.round(input.hours * 60),
});
} catch {
} catch (error) {
// The client only ever sees the generic message below — a validation
// constraint is not sensitive, but there is no reason to expose
// PocketBase's internals to the browser. The real reason still needs to
// be discoverable without re-deriving it by hand, so it goes to the
// server log.
console.error("[log-work] commit create failed:", error);
return { ok: false, message: "Could not save that entry" };
}