Almanac-Main-Full-Stack-Calendar · port 5003
Booking, and the email that has to go out exactly once
A multi-role scheduling app — client, provider and admin, each with their own dashboard, over one slot engine. Two things in it are harder than they look: turning recurring weekly hours into a live list of free slots without ever offering the same one twice, and sending five kinds of automatic email in a way that survives overlapping scans, a double-clicked button and several workers at once.
What a free slot is, and what it has to survive
domain/calendar_logic.py turns a provider's recurring weekly hours,
their one-off blocked dates and their existing bookings into the list of
times a client may actually pick, for any date.
This is the one piece of Almanac that needs no server, so it is published
on its own: set some hours, add a block or a booking and
watch the slots change → It is the engine and nothing else — no
account, no database, nothing saved — and the JavaScript it runs is a port
of the same module, which tools/build_static.py checks against
the Python in a real browser and refuses to publish on a single
disagreement.
Five messages, each sent exactly once
All five go out without anyone pressing a button. The difficulty is not sending them; it is not sending them twice.
| When | Who gets mailed |
|---|
Nobody is mailed twice
A unique index on
email_log (appointment_id, kind, recipient) is the source
of truth rather than a flag somebody remembers to set, so overlapping
reminder scans, a double-clicked button and several web workers
running at once all collapse to one message.
Nothing blocks, and nothing is lost
mailer.send() writes a row and hands the message to a
worker thread; the booking request returns immediately. A refused SMTP
connection is a logged failed row rather than a 500, and
the next reminder scan picks it up again.
Coffee chats: an email that produces a booking
The reverse of the usual direction. You send someone an invite, they click the link, they see your real availability, they pick a time — and they never make an account.
Every module, by size
Where the tests are
| Module | Lines | Stmts | Covered | What it does |
|---|
Bugs, and what found each one
Six of these were reachable by a logged-in provider editing their own hours — and then hit by every client trying to book them. None was found by reading the code.
| What was wrong | What found it | State |
|---|
The key that signs every session
The development fallback for SECRET_KEY is committed, so it
is public. A deployment that kept it is one where anybody could mint a
valid admin token.