eleith/when
1
1 Fork 0
Code Issues Pull Requests Packages Releases Activity

Host booking form hides conflict errors returned by private actions #86

New Issue
Closed
opened 2026-10-24 00:00:59 +00:00 by eleith-gitea-agent · 0 comments
eleith-gitea-agent Bot commented 2026-10-24 00:00:59 +00:00
Copy link
Copy source

Observed

The signed-in host books from the public scheduler, whose form posts to a private admin action. When that action rejects the booking, its error is returned correctly but never displayed on the current page. The form remains visible with entered values and no explanation.

Reproduced against landed main aee8312b54, using isolated production-build Chromium. This predates the in-progress host duration-choice work.

Steps to reproduce

  1. Sign in as host and open /schedule/{meeting}.
  2. Pick an available slot, advance to the guest-details step and fill in valid fields.
  3. Before submitting, make that selected interval busy through another booking/session.
  4. Submit the host booking form.

Expected: display the server's conflict explanation and allow correction/reselection, preserving entered fields.
Actual: no visible error; the form appears unchanged even though the server rejected it.

Confirmed runtime evidence

On the isolated fixture, a conflicting confirmed appointment was inserted after the real UI selected a slot. The form action was /admin/schedule/chat while the current page was /schedule/chat. Native enhanced submission returned:

{"type":"failure","status":409,"data":"[{\"error\":1},\"That time is no longer available. Please pick another.\"]"}

There were zero .form-error elements, and the expected alert remained absent during the browser assertion. Name/email values stayed populated. A screenshot and response evidence were saved with the isolated reproduction.

The outer HTTP 200 used for SvelteKit's JSON action envelope is not the bug; the contained 409 failure was correct. Its presentation is missing.

Cause / relevant ownership

  • apps/web/src/lib/components/AppointmentWizard.svelte selects /admin/schedule/... for a host while rendering on /schedule/....
  • GuestForm.svelte uses plain use:enhance and renders errors only from its form prop.
  • SvelteKit's default enhancement does not apply failure data to the current page's form when action/current pathnames differ.

Host rescheduling uses the same cross-path form wiring and should be checked as part of the fix; the isolated runtime reproduction above specifically exercised host creation.

Bounded acceptance

  • Render cross-route host action errors and field errors where the host is editing.
  • Preserve entered fields, selected length and useful correction state on rejected submissions.
  • Keep success redirects, authentication and guest endpoint restrictions unchanged.
  • Add browser regressions for a real host conflict and relevant validation failures; verify host rescheduling separately.
  • Do not automatically resubmit or imply rollback when an operation may already have committed. No generic error framework or polling is needed.

No live application data, provider/SMTP calls or service restarts were used. Duplicate check covered open and closed issues; closed #46 discusses general form improvements but does not report this cross-route host failure.

## Observed The signed-in host books from the public scheduler, whose form posts to a private admin action. When that action rejects the booking, its error is returned correctly but **never displayed on the current page**. The form remains visible with entered values and no explanation. Reproduced against landed main **aee8312b54a60254282007abaaa3bd6241ecbef6**, using isolated production-build Chromium. This predates the in-progress host duration-choice work. ## Steps to reproduce 1. Sign in as host and open /schedule/{meeting}. 2. Pick an available slot, advance to the guest-details step and fill in valid fields. 3. Before submitting, make that selected interval busy through another booking/session. 4. Submit the host booking form. Expected: display the server's conflict explanation and allow correction/reselection, preserving entered fields. Actual: no visible error; the form appears unchanged even though the server rejected it. ## Confirmed runtime evidence On the isolated fixture, a conflicting confirmed appointment was inserted **after** the real UI selected a slot. The form action was /admin/schedule/chat while the current page was /schedule/chat. Native enhanced submission returned: ```json {"type":"failure","status":409,"data":"[{\"error\":1},\"That time is no longer available. Please pick another.\"]"} ``` There were **zero .form-error elements**, and the expected alert remained absent during the browser assertion. Name/email values stayed populated. A screenshot and response evidence were saved with the isolated reproduction. The outer HTTP 200 used for SvelteKit's JSON action envelope is **not** the bug; the contained 409 failure was correct. Its presentation is missing. ## Cause / relevant ownership - apps/web/src/lib/components/AppointmentWizard.svelte selects /admin/schedule/... for a host while rendering on /schedule/.... - GuestForm.svelte uses plain use:enhance and renders errors only from its form prop. - SvelteKit's default enhancement does not apply failure data to the current page's form when action/current pathnames differ. Host rescheduling uses the same cross-path form wiring and should be checked as part of the fix; the isolated runtime reproduction above specifically exercised host creation. ## Bounded acceptance - Render cross-route host action errors and field errors where the host is editing. - Preserve entered fields, selected length and useful correction state on rejected submissions. - Keep success redirects, authentication and guest endpoint restrictions unchanged. - Add browser regressions for a real host conflict and relevant validation failures; verify host rescheduling separately. - Do not automatically resubmit or imply rollback when an operation may already have committed. No generic error framework or polling is needed. No live application data, provider/SMTP calls or service restarts were used. Duplicate check covered open and closed issues; closed #46 discusses general form improvements but does not report this cross-route host failure.
eleith-gitea-agent Bot added the bug label 2026-10-24 00:00:59 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Labels
Clear labels
blocked
Waiting on a prerequisite before work can proceed
 bug
Something is not working
 enhancement
New feature
No labels bug
Milestone
No items
No Milestone
Assignees
Clear assignees
eleith-gitea-agent Bot eleith (eleith)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: eleith/when#86