MixMan's Production Contract Is Taking Shape

As of 14 August 2026, MixManServer's dev branch and the public service are both running revision 5061cfa. The live readiness response reports session contract v3, an observable database pool, and no recorded pool timeouts.

That is a useful milestone. It means the current code is not merely sitting on a development branch: the exact revision has passed through the deployment path and is live. It does not, however, mean that every production-only behavior has the integration coverage we want. That distinction is the subject of MixManServer issue #37.

What has landed recently

Several changes have improved the system around that contract.

Session database work now runs away from FastAPI's event loop, with a regression test proving that a blocked session write does not stall an unrelated health request. Media responses already use short database lifetimes, and the experience event stream polls through fresh sessions rather than retaining one transaction indefinitely.

The player also gained stricter cancellation of stale audio prefetches. This is important in a multi-tab application: abandoned prefetch work should not consume network, memory, or server capacity after the player has moved on.

The build and deployment path has improved too. MixMan workflows are serialized against one host-wide capacity lease, dependency and image checks have been tightened, and a bounded ARM64 dependency smoke now runs on relevant changes and on a weekly schedule. TotalInfra has also activated a carefully constrained temporary 4 GiB execution tier with disposable build storage, fixed resource ceilings, and cleanup reconciliation.

These are meaningful operational improvements. They reduce event-loop stalls, stale browser work, overlapping builds, and unbounded cleanup risk.

Why ordinary pytest still uses SQLite

Most of MixMan's Python tests should continue to use SQLite. It is fast, deterministic, and well suited to the broad application suite. Moving every test to MariaDB would make routine feedback slower without making most assertions more valuable.

The missing piece is a small production-contract lane for behaviors SQLite and jsdom cannot prove.

MariaDB matters where transaction visibility, row locking, competing claims, and isolation semantics affect correctness. A real browser matters where shipped HTML, module ordering, cookies, CSRF transport, session storage, multiple tabs, and event streams interact during startup.

The current required workflow already leases an isolated, run-scoped MariaDB database and exercises two real-database cases: atomic review promotion and a stale lease-snapshot scenario. That is solid groundwork, but it is not yet the complete contract.

What remains for issue #37

The browser side still needs to boot the shipped Policy Console, Jukebox, desktop Player, and mobile Player in a pinned real browser engine. Those tests must exercise the controls people actually use, not only import helper modules under jsdom.

The highest-value browser cases are:

• proving that the first same-origin mutation in an OIDC cookie session carries the CSRF header;
• opening two tabs of the same surface and proving they receive distinct instance identities;
• opening different surfaces in one browser context and proving heartbeat, disconnect, and authority ownership cannot cross identities; and
• surfacing startup failures with bounded retry instead of leaving a rendered but inert interface.

The MariaDB side still needs focused coverage for competing session and worker claims, transaction visibility, committed SSE events becoming visible without reconnecting, concurrent idle streams not exhausting the pool, and slow audio, artwork, and review streams releasing database connections before response bodies finish.

The weekly ARM64 smoke is useful, but it is not the heavier scheduled contract lane described by #37. Longer fan-out, cancellation, slow-stream, and contention exercises still need their own isolated schedule and failure evidence.

The infrastructure dependency

TotalInfra issue #25 owns the larger architectural dependency: a repository-scoped remote runner with a pinned browser runtime, disposable MariaDB, and immutable artifact handoff.

The temporary 4 GiB tier makes present-day CI safer and gives us somewhere practical to develop the contract suite. It does not replace the final design. The production host should eventually verify and deploy the exact remotely tested image digest, rather than also carrying the full browser, test, and multi-gigabyte build workload.

That boundary keeps production credentials on the production host and keeps remote CI away from the production database and general production network.

The next execution

The next pass is now quite concrete:

1. bring the working checkout to the current dev revision;
2. resolve the frontend audit work in issue #45 while pinning the browser toolchain;
3. add the small real-browser and MariaDB production-contract suites while leaving ordinary pytest on SQLite;
4. wire an unskippable pre-deployment contract stage and a separate heavier scheduled stage;
5. finish the remote runner and immutable artifact handoff in TotalInfra; and
6. require a green, unskipped run and verify the deployed revision before closing #37.

MixMan is healthy and current in production. The remaining work is no longer a vague request for "more integration tests." It is a bounded contract around the handful of browser, database, streaming, and deployment behaviors that only production-like conditions can prove.