qo
Qovery
GitHub
console
Workspace
GitHub
CI Pipeline Executions
Filtered
Runs
Demo
Insights
Compare tasks
Analytics
Sign in
Toggle sidebar
Overview
⌘K
console
Loading workspace stats
Loading workspace insights...
Statistics interval
7 days
30 days
Latest CI Pipeline Executions
Status
Fix filter
Filter
Fuzzy
Filter range
Sort by
Sort by
Start time
Sort ascending
Sort descending
Succeeded
2912
b2ddcae8 fix(blueprint): show why an update preview timed out What: The preview socket's timeout branch now reads the frame's `message` and passes it to the failure panel as `reason`, exactly as the error branch already does. The domain outcome gains an optional `message` to carry it. Why: The engine now bounds a preview's terraform run and reports hitting that bound as a timeout naming which step ran out of time and after how long, which q-core publishes as `{"type":"timeout","message":...}` instead of an error. The console discarded that message, so shipping the backend work alone would have been a net regression: the same condition arrives today as `type=error`, whose message the console *does* render, so users would have gone from a specific reason to "The preview timed out before completing." and nothing else. Notes: `message` is optional because two producers have no reason to report: the 12min client-side watchdog, and the gateway's own synthesized frames. `TimeoutFrame` exists only because the pinned qovery-ws-typescript-axios (0.1.644) predates the field. The field is on the wire today, so reading it is correct before the client bump; the generated websocket schema now declares it `string | null` and not required, so the alias can be deleted once the client is regenerated. Worth knowing for the next person: nothing here could have failed a build. The WS layer is an unvalidated `JSON.parse`, ts-pattern matches structurally, and `.exhaustive()` checks variants rather than fields — so a dropped field is invisible to both the type checker and the tests.
by Antoine
A
Previous
Next