fix(membership): keep the partial-delivery warning on screen #53
No reviewers
Labels
No labels
bug
discussion
enhancement
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
edufeed/edufeed-app!53
Loading…
Reference in a new issue
No description provided.
Delete branch "fix/membership-partial-delivery-visible"
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?
The partial-delivery warning was set and then destroyed on the same tick, so it never painted a frame. Found by TestOER against merged
devwith a relay proxy that answersOK: falseto events p-tagged to the second admin.The bug
MembershipApplicationForm.svelteends a submit with:partialDeliveryrenders inside{:else if submitted}— a branch that only becomes reachable on the tickMembershipApplyModalunmounts the form via itsonsubmittedhandler. TestOER sampled the DOM every 100 ms for 15 s and got zero frames with the warning.This is the only signal an applicant gets that a reviewer was missed and the review may sit longer than usual. The surface behind the modal cannot carry it — it flips to "waiting for review" off the mirrored event, which a partial fan-out still produces.
The change
onsubmittednow receives the delivery outcome, and the modal stays open on a partial so the applicant can read the warning and dismiss it themselves. A clean submit closes exactly as before.SignupModalis unaffected: it keeps the form mounted undercurrentStep === 5, so the warning already rendered there. I confirmed that by reading —handleAppliedonly switches the footer button, it does not change step.Why the suite was green
MembershipApplicationForm.test.js:505renders with noonsubmittedprop, so nothing tore the form down andfindByTestIdresolved. The test was correct about the state and blind to the lifecycle. New coverage sits at the modal, where the lifecycle actually exists.Verification
pnpm check0 errors.handleSubmittedreverted to always close, the new "stays open" test fails. It tests the fix.One thing to know about
pnpm teston devEvery run reports
Errors: Nfrom anEnvironmentTeardownErrorinGlobalFAB.test.js— a lazysvelte/reactivity/media-queryimport landing after teardown. All tests pass; the run still exits non-zero.I nearly attributed it to this branch. Two baseline runs on clean
devcame back with 0 errors, which looked like proof. Sampling five runs each says otherwise:Same distribution, and the callstack contains no membership code. It is a pre-existing race on
dev, and it means CI ondevis red at random.The warning that an application reached only some admins was set and then destroyed on the same tick. `submitted = true; onsubmitted?.()` runs back-to-back, and MembershipApplyModal's onsubmitted closed the modal — so the `{:else if submitted}` branch that renders the warning became reachable exactly as ModalManager unmounted it. It never painted a frame. That is the only signal an applicant gets that a reviewer was missed and the review may sit longer than usual. The surface behind the modal cannot carry it: it flips to "waiting for review" off the mirrored event, which a partial fan-out still produces. onsubmitted now receives the delivery outcome, and the modal stays open on a partial so the applicant can read the warning and dismiss it themselves. A clean submit closes as before. SignupModal is unaffected — it keeps the form mounted under `currentStep === 5`, so the warning already rendered there. The suite was green on this because MembershipApplicationForm.test.js renders with no onsubmitted at all, so nothing tore the form down. The new coverage is at the modal, where the lifecycle actually exists. Found by TestOER against dev @2f507ff5, using a relay proxy that answers OK: false to events p-tagged to the second admin. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>