feat: Auto-Cancel — email CSC one request for every pending cancellation

[pataniaeli]

New feature, no issue number. Branched off dev. No migration needed.

An admin opens Cancellations → Auto-Cancel, optionally narrows by booking type and date range, reviews the list, and sends CSC a single email asking for each reservation to be released. Every booking marked Pending Cancellation is collected; each line carries date, time and reservation code.

The part worth reading twice

weekly_room_occurrences.status is an override, where NULL means "inherit from the series" — 340 of the 385 occurrence rows carry a NULL status.

So a series marked Pending Cancellation has occurrences that are pending without any occurrence row saying so. Matching on the occurrence's own column would have silently skipped every series-level cancellation — the case with the most dates behind it. Room, times and reservation code inherit the same way, so each is resolved against the series before it reaches the email.

That resolution is a pure exported function (resolveOccurrence) precisely because it's the piece most likely to be wrong and the hardest to observe: no series is currently pending, so there's no live data to exercise it. It's unit-tested with synthetic rows instead.

Decisions I made — worth confirming

Nothing changes status. The email asks CSC to release the rooms. CSC is the authority on whether that happened, and marking anything Cancelled here would assert an outcome Chambers hasn't been told. The existing "Mark as Done" control stays the step that closes the loop. The success screen says this explicitly so nobody assumes otherwise.

Two guards, because this is the only mail Chambers sends outside SGA and it can't be recalled:

• The admin approves the actual list, not a count.
• The send re-runs the query server-side rather than trusting the posted body — otherwise a client could mail any set of dates and codes it liked to an external address. The reviewed count travels with the request and a mismatch answers 409 rather than sending a list nobody agreed to.

The send is awaited, not deferred like the member-facing emails. It's the entire point of the request, and an admin told it went needs that to be true; a failure returns 502 and says nothing was changed.

Reservations with no code are listed, not dropped — flagged amber in the preview and marked in the email. CSC can find those by date and room; silently omitting them would lose a cancellation.

Recipient defaults to cscreservations@northeastern.edu, overridable via CSC_EMAIL so staging can point somewhere harmless. Replies go to OPS_EMAIL, not the no-reply sender.

Known gap for you to decide

Nothing records that a request was sent. Running Auto-Cancel twice re-sends the same reservations, since the bookings stay Pending Cancellation until CSC confirms. Options: a csc_requested_at column, or a small send-log table. I didn't invent schema for it — say which you'd prefer and I'll add it.

Verification

Run against the live database with the Resend client intercepted, so nothing was sent. Probes removed before committing.

Check	Result
Collector vs. independent SQL	exact match — same 6 rows, codes, rooms, bodies, ordered by date then time
Type filters	tabling 0 · one-time 0 · weekly 6
Date bounds	from 2 · to 4 · range 1
Malformed date	rejected, falls back to no limit
Inheritance: all-NULL occurrence	resolves to series' Pending Cancellation — would be caught
Inheritance: occurrence override	beats the series; partial inherit works
Inheritance: no series	safe fallbacks, no crash
Email	correct recipient + reply-to, table fits the 600px frame, no cell overflow
Modal	filters update the count live, send disabled on empty list, POST carries reviewed count
Auth	GET and POST both 401 unauthenticated

Typecheck, lint and build clean. The one lint error in cancellations-tab.tsx is pre-existing — confirmed on the stashed baseline.

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
chambers	Ready	Preview	Sep 9, 2026 3:39pm UTC

[pataniaeli]

Added 267f63f with all three changes.

1. Sending now cancels

The reservations in the request are marked Cancelled once CSC has been asked.

Order is deliberate: the email goes first, statuses move only after it is accepted. Marking first and then failing to send would leave a booking cancelled in Chambers that CSC still holds a room for — the one outcome worth designing against, because nobody would go looking for it. If the mail fails, nothing is touched and the response says so.

An occurrence whose status was inherited gets Cancelled written onto the occurrence itself, so only the dates actually sent stop being pending and the rest of the series is untouched.

Each affected booking also gets an audit_logs row, so this shows up in the Audit tab beside every other status change rather than looking like it happened by itself.

2. Codeless reservations dropped

A reservation code is the only handle CSC has on a booking, so one without it can be neither requested nor — now that sending cancels — cancelled, since that would put Chambers and CSC out of step over a request CSC could not act on.

They are set aside and shown, in the preview and on the confirmation, because they are still outstanding and someone has to chase them by hand. Whitespace counts as absent: a code column holding " " is a blank someone tabbed through.

3. Ops copied

cc: OPS_EMAIL on every request, so the division holds the record rather than only the sender's mailbox. Reply-to unchanged.

This closes the duplicate-send gap

The open question from the original PR resolves itself: marked-Cancelled rows no longer match the query, so a second run cannot re-send them. No extra column or send-log table needed.

Verification — no mail sent, nothing written

Check	Result
Code rule	rejects null / undefined / "" / " "; accepts a real code, padded or not
Email headers	to CSC, cc sgaOperations@northeastern.edu, reply-to set
Update targets exist	6/6 ids resolve to real occurrence rows
Audit parents correct	6/6 booking ids are the true parents
All still pending	6/6
Pending rows missed	0

That last block was run read-only against the database, so the UPDATE is confirmed to hit exactly the intended rows and nothing else — without executing it.

Through the real modal with skipped rows present: coded reservations listed, codeless ones in their own amber block marked not sent and not cancelled, footer naming both recipients, and the confirmation reporting what was cancelled and what was left alone.

[pataniaeli]

Added 773023f — rescoped from filter-driven to explicit selection.

Why this was the right call

Filters decided what got cancelled. Once sending also marks bookings Cancelled, a mis-set filter stopped being a bad email and became a batch of bookings cancelled without anyone choosing them.

The button now returns every reservation currently marked Pending Cancellation, and the admin ticks the ones to include. Nothing is selected when the modal opens — including a reservation is an act, not a default, since the send is both an email to an office that will act on it and a status change, neither reversible.

The filters are gone, not kept alongside

Two mechanisms for choosing what gets cancelled — one of which quietly hides rows — is how this went wrong in the first place. If the list ever grows enough to need finding rather than reading, a filter that narrows only what is displayed can come back, with selection staying explicit. Say the word if you want that now.

The security property is preserved

The selection is a choice among what the server finds, never the source of truth. Each row is named by a key scoped to its table, and every submitted key is matched back against a freshly collected set before anything is sent. A client cannot introduce a date, a code, or a booking that is not currently pending with a code on file; the list reaching CSC is built from the server's own rows.

A key that no longer resolves fails the whole request, not just that row. Sending the remainder would cancel a different set from the one the admin reviewed, and they would have no way to tell which.

Verification — no mail sent, nothing written

Check	Result
Keys unique + table-scoped	✅ source:uuid
Valid subset	resolves exactly, 0 missing
Unknown key	resolves to nothing, reported
Same uuid, wrong table prefix	resolves to nothing — the reason the key carries its table
Mixed valid + stale	reports the bad one → route refuses the batch
Auth	GET and POST both 401

Through the real modal: 3 rows, none ticked, send disabled and recipient line hidden; ticking one enables it and names both recipients; select all / clear all move between 3 and 0; ticking the first and third posts exactly those two keys with the middle row excluded.

Worth noting the live pending list moved from 6 to 7 while I was working, which the list picked up — a good reminder of why the stale-key check refuses rather than proceeds.

[pataniaeli]

Added c3adc12. You were right — this was a real correctness bug in what I built.

cancellation_requests.cancellation_type is Cancellation | Virtual (CHECK-constrained), and Virtual is already a status the rest of Chambers understands. Marking everything Cancelled was wrong for the second: a virtual meeting still happens, it just does not need the room.

Resolution rules

Each pending reservation now resolves its own outcome:

• A request naming the exact week wins over one covering the series.
• One-time and tabling rows match on their booking.
• Requests are read once and indexed, ordered so a still-Pending request beats a resolved one and the most recent beats an older one.

The fallback turned out to matter more than the mapping

Of the 7 reservations pending right now, 4 have no cancellation request behind them at all — a booking can be set to Pending Cancellation directly by an admin. So the default is the common path, not an edge case.

Those fall back to Cancelled: it is the plain reading of an admin marking something for cancellation, and going virtual is a specific thing a requester asks for. Defaulting the other way would quietly leave rooms marked as still meeting.

Those rows are labelled in the list — "no request on file — defaulting" — because a row taking a default rather than a stated intent is the one worth a second look before approving.

Other bits this touched

• Updates grouped by table and status, so a mixed batch writes each its own value.
• Audit rows keyed the same way — one booking can contribute both a cancelled week and a virtual one, and a single row saying Cancelled would misreport the other.
• The send button stops claiming "mark cancelled" once a Virtual is selected; it reads "apply statuses" instead.
• CSC's side is unchanged — either way the reservation is released, so the email asks for exactly that.

Verification — nothing written, no mail sent

outcomeOf unit results:

Input	Status	fromRequest
Virtual	Virtual	true
Cancellation	Cancelled	true
null / undefined / unrecognised	Cancelled	false

Resolved across the 7 live pending reservations: 6 Cancelled, 1 Virtual, 4 defaulted — matching an independent SQL join row for row, including the one Virtual (code 695614) and the two explicit Cancellation requests.

Through the real modal: each row carries its outcome badge, the defaulted row is labelled, the button reads "Send & mark cancelled (2)" for a Cancelled-only selection and flips to "Send & apply statuses (3)" once the Virtual is added, and the confirmation reads "2 now marked Cancelled, and 1 marked Virtual — those meetings still happen, without the room."