CRESA Repairs Its Browser Request Pipeline

Fixing the System Underneath the Alerts

Certification had exposed severe request queueing inside CRESA's shared browser infrastructure. What initially appeared during alert testing turned out to be a much deeper runtime problem, with persistent HTTP connections, duplicated polling and accumulating resources gradually slowing requests that should have been almost immediate.

Development focused on repairing that shared path rather than changing individual alerts to hide the symptoms.

Removing Work CRESA Did Not Need

Investigation found duplicate alert polling taking place in the browser runtime. That unnecessary polling was removed so alert state could continue flowing through the shared alert system without multiple pieces repeatedly asking the engine for the same information.

The HTTP path was also tightened around reusable connections and bounded idle cleanup. CRESA could keep the efficiency benefits of persistent connections while preventing abandoned sockets and workers from accumulating indefinitely.

Seconds Become Milliseconds

The difference after the repair was substantial. During the failing certification environment, the main alert-state request had reached a median response time of roughly 2.9 seconds, while the Simulation Lab alert-state route was around 3.3 seconds.

After the repair, those same paths dropped to approximately 1.2 milliseconds and 98 milliseconds respectively. Static assets were also being served at around a 15 millisecond median, while connection reuse reached 474 of 475 requests during validation.

A Stable Engine Again

The repair also stopped the resource buildup that had accompanied the slowdown. The engine stabilised at roughly 41 threads during validation without the previous accumulation of connections waiting to close.

Alert scenarios including stacked presentation, Quiet behaviour, presentation handoff, redemption events and cleanup could then run successfully on top of the repaired infrastructure.

Back to Certifying the Features

With the shared bottleneck removed, the alert system could finally be judged on its own behaviour again. The engine test suite completed 463 out of 463 tests, while the certification suite completed 9 out of 9 automated checks.

Phase 2 still had visual presentation reviews to complete, but the infrastructure blocking meaningful certification was gone. More importantly, CRESA had come out of the investigation with a faster and considerably more stable browser request pipeline than the one it entered with.