DB2 Cutover Friction, Calendar Routing, and the Email 3.0 Pivot
This stretch did not begin like a clean new feature arc. Brett was still recovering from the previous board-engine work, the sessions kept restarting, and the biggest discoveries came from what failed when the admin frontend tried to lean on DB2 more aggressively. Calendar requests were still falling through to the wrong handler, pagination was lying about totals, and the email system was halfway between its old account tables and a much larger mailbox-first future.
Where the pressure was coming from
By late November the project was deep into its progressive DB2 cutover. The goal was no longer just to prove the new database worked — it was to make sure specific admin pages could hit the right schema every time, even when the broader cutover flag still allowed legacy behavior to linger.
That is why this arc matters. The board work from the earlier DataHub sessions exposed a more general problem: some pages needed a guaranteed DB2 path regardless of whatever fallback logic still existed elsewhere.
What actually happened
The first sessions in this span were still carrying workspace-board momentum, but the important story was the debugging underneath it. Brett pushed the admin frontend toward DB2-only routes, especially through the /api/pdb/v1 family, so the users page, profile flows, messenger/forum assets, calendar, and settings diagnostics could stop drifting back onto the legacy path. The users page also had to stop pretending it knew the real totals — pagination metadata had to come from the DB2 response rather than the older schema.
Calendar was the stubborn exception. Even after the frontend was pointed at the DB2-safe route family, one of the failing POSTs still produced the old legacy relation name, which meant the request was almost certainly slipping into the wrong router. That did not get cleanly resolved here. The real historical point is that the team now understood the bug more clearly: this was not just a missing table, it was a route-resolution problem during a live cutover.
Then the arc pivoted sideways into email. An HR/email/workspace audit turned into the start of Email 3.0: a mailbox-based data model, queue workers for sync/delete/outgoing flows, dual-write behavior so the old and new tables could coexist during migration, and a settings experience that treated mailbox health and queue state as first-class operational surfaces instead of hidden background behavior.
The follow-up session on November 26 pushed that further. /api/v1/me/email was rewritten around mailboxes, mailbox_user_access, and mailbox preferences. The settings page was reorganized around mailbox cards. Queue sync became a visible action. Analytics started aiming at queue throughput and mailbox health rather than vague personal inbox status. And the reader itself shifted toward a plain-text-first approach with on-demand rich HTML loading so the app always had a lightweight view ready even when deeper content was still being hydrated.
The shape of the change
| Before | After |
|---|---|
| DB2 was present but some admin pages still quietly depended on legacy fallback behavior | Critical pages were explicitly retargeted to DB2-safe endpoint families |
| Calendar failures looked like generic schema breakage | The problem was narrowed to legacy-vs-DB2 route handling during cutover |
| Email settings still revolved around older account tables | A mailbox-first Email 3.0 model started to take over |
| Background email work was hard to observe | Queue workers, queue stats, mailbox health, and sync controls became visible design goals |
What did not get magically solved
This is one of those sessions where accuracy depends on resisting the tidy version of the story.
- Calendar was not fully fixed.
- Email 3.0 was not complete or cleanly migrated.
- The dual-schema tension inside email was still real.
- The analytics work was moving toward observability, not declaring victory.
What Brett did accomplish was more durable than a polished finish: he forced the architecture to reveal where the seams still were.
Why this mattered later
The very next substantive work moved into the HR systems, Contracting Hub, and Policy Studio push. But this DB2/email interval left behind two patterns that kept resurfacing:
- if a route absolutely had to be on DB2, it needed an explicit path and explicit verification; and
- if a background system mattered operationally, it needed visible health and queue surfaces instead of optimistic assumptions.
That second lesson is why the email monitoring arc came back again in December. The architecture had moved forward here, but the proof that it was telling the truth still had to be built.