moltis-org/moltis - CodSpeed

moltis

Blog Docs Changelog

Performance History

Latest Results

fix(web): don't wait for sandbox image build in build_gon_data Root cause found via gateway.log tracing: router.default_image() calls wait_for_build_if_needed() which blocks up to 10 MINUTES waiting for the initial sandbox image build to complete. Every SPA page request during the build hangs until the 10s timeout fires. Added resolve_default_image_nowait() that skips the build wait — the gon data just needs the configured image name, not the fully built image. The image_building flag already tells the UI whether a build is in progress. Gateway log evidence: gon: heartbeat_runs elapsed_ms=17 [10 second gap — default_image() waiting for build] spa_fallback: SLOW response elapsed_ms=10133

main

24 seconds ago

fix(e2e): use pipe tee without exec for gateway log capture

main

50 minutes ago

fix(e2e): fix gateway log capture using process substitution tee

main

2 hours ago

fix(web): add warn-level tracing to SPA handler + capture gateway logs in CI Added tracing to auth_gate middleware and spa_fallback handler to identify WHERE the page request hangs on CI. Gateway stderr is now redirected to gateway.log and uploaded as a CI artifact. If the gateway log shows no "spa_fallback: entered" trace, the hang is in the middleware or connection layer. If it shows "entered" but no response, it's inside build_gon_data or render_spa_template.

main

3 hours ago

fix(web): bypass std::sync::Mutex in onboarding_completed for async safety onboarding_completed() called wizard_status() which acquires a std::sync::Mutex and does filesystem I/O (path.exists()) — both block the tokio async runtime. On CI runners with few CPUs, this starves the worker threads, causing page requests to hang. Replaced with a direct spawn_blocking check of the .onboarded sentinel file, bypassing the mutex entirely. Verified with local stress test: 150 concurrent requests with 1 tokio worker = 0 failures.

main

3 hours ago

fix(web): wrap remaining blocking I/O in build_gon_data with spawn_blocking ManifestStore::load() reads the skills manifest from disk via std::fs::read_to_string on every page request. resolve_channels_offered() calls find_config_file() + load_config() which do multiple filesystem stat/read operations. Both ran directly on the async worker thread. Wrapped both in tokio::task::spawn_blocking to prevent blocking the async runtime on low-CPU CI runners.

main

4 hours ago

fix(web): move blocking syscalls out of async runtime in build_gon_data collect_mem_snapshot() calls sysinfo::System::new/refresh_memory/ refresh_processes which are blocking syscalls reading from /proc. detect_git_branch() does blocking filesystem I/O via gix::discover. On CI runners with few CPUs, these blocking calls on the async runtime starve tokio workers, causing concurrent page requests to time out while health endpoint (which doesn't call build_gon_data) responds fine. Wrapped both calls in tokio::task::spawn_blocking so they run on the blocking thread pool instead of the async worker threads. Reverted the worker_threads=4 workaround — the proper fix is to not block the async runtime.

main

4 hours ago

fix(web): add 10s timeout around build_gon_data and warn-level tracing build_gon_data can deadlock on CI, hanging SPA page responses indefinitely while the health endpoint responds fine. Added: - 10s tokio::time::timeout around build_gon_data — returns 500 error page instead of hanging forever - warn-level tracing at each step to identify which service call hangs - Moved build_gon_data before the template match so timeout applies to all three SPA templates (Index, Login, Onboarding) - Reverted start-gateway.sh tee (broke exec)

main

5 hours ago

Latest Branches

+13%

Update local TTS provider docs#962

10 hours ago

d7b55ed

able-fluorine

+26%

fix(providers): replay DeepSeek reasoning content#961

10 hours ago

c19209c

modest-search

-11%

fix(matrix): add debug logging for OIDC registration and deduplicate redirect normalization#957

1 day ago

ea92fcc

festive-plume

© 2026 CodSpeed Technology

Home Terms Privacy Docs