Bug: production slugkit.com errors lack server-side logging #7

New issue

Closed

opened 2026-06-27 11:11:34 -05:00 by erik · 2 comments

erik commented

2026-06-27 11:11:34 -05:00

Owner

Problem

Production slugkit.com can return sanitized error messages to the browser without logging the underlying server error.

Observed during passkey registration: the UI showed Could not verify passkey registration, but k3s pod logs had no passkey-specific error, stack trace, or verification context.

Expected

All caught production errors should be logged before returning sanitized responses.

Scope

Ensure deployment/runtime logging captures caught app errors from slugkit routes.
Verify /settings/passkeys/register failures are visible in pod logs.
Avoid logging secrets, tokens, cookies, or full WebAuthn credential payloads.
Prefer structured logs with route/action, status, safe user context, and exception stack.

Acceptance criteria

A failed passkey registration produces a useful log entry in k3s pod logs.
Operational runbook/debug notes identify where to look for these logs.
Sanitized browser responses remain safe.

## Problem Production slugkit.com can return sanitized error messages to the browser without logging the underlying server error. Observed during passkey registration: the UI showed `Could not verify passkey registration`, but k3s pod logs had no passkey-specific error, stack trace, or verification context. ## Expected All caught production errors should be logged before returning sanitized responses. ## Scope - Ensure deployment/runtime logging captures caught app errors from slugkit routes. - Verify `/settings/passkeys/register` failures are visible in pod logs. - Avoid logging secrets, tokens, cookies, or full WebAuthn credential payloads. - Prefer structured logs with route/action, status, safe user context, and exception stack. ## Acceptance criteria - A failed passkey registration produces a useful log entry in k3s pod logs. - Operational runbook/debug notes identify where to look for these logs. - Sanitized browser responses remain safe.

erik added the

labels

2026-06-27 11:11:34 -05:00

erik commented

2026-06-27 11:17:08 -05:00

Author

Owner

Synced from todu comment by @todu on 2026-06-27T16:16:42.022Z

Review update

PR: erik/slugkit.com#8 is open and reviewed.
Result: approved.
Follow-up: waiting for explicit human merge approval.
Acceptance criteria: 3/3 met; no blocking issues or warnings.

_Synced from todu comment by @todu on 2026-06-27T16:16:42.022Z_ ### Review update - PR: `erik/slugkit.com#8` is open and reviewed. - Result: approved. - Follow-up: waiting for explicit human merge approval. - Acceptance criteria: 3/3 met; no blocking issues or warnings.

erik

2026-06-27 11:22:40 -05:00

closed this issue
added
status:done
and removed
status:inprogress
labels

erik commented

2026-06-27 11:22:41 -05:00

Author

Owner

Synced from todu comment by @todu on 2026-06-27T16:17:45.800Z

Closing summary

PR erik/slugkit.com#8 was reviewed, approved, merged into main, and local main was fast-forwarded.
Acceptance criteria are met per review evidence: failed passkey registration logging, runbook/debug notes for locating logs, and safe sanitized browser responses.

Ready to close.

_Synced from todu comment by @todu on 2026-06-27T16:17:45.800Z_ ### Closing summary - PR `erik/slugkit.com#8` was reviewed, approved, merged into `main`, and local `main` was fast-forwarded. - Acceptance criteria are met per review evidence: failed passkey registration logging, runbook/debug notes for locating logs, and safe sanitized browser responses. Ready to close.