Fuga Moves Disk Maintenance Into Its Execution Backend

Fuga's latest committed development brings disk maintenance into the independent execution backend. The change addresses several sources of local storage growth around agent runs: backend event journals, generated application builds, and completed run checkouts. Its organizing idea is ownership. A backend that knows which runs are live, which generation is current, and when it is handing off can make more informed maintenance decisions than a detached file cleanup routine. The code expresses that design; the available evidence does not establish how much space it saves in use.

Maintenance follows the backend lifecycle

The backend host now starts a disk maintenance controller after it has constructed its Arena manager and registered retained running agents. The controller schedules a first pass after one minute and subsequent passes every five minutes. Each pass attempts to archive eligible retired journals, checks for retired build outputs, reads available filesystem space, and then invokes the existing garbage collection sweep with live run identifiers and resumable or interrupted run listings. It reports a summary for inspection. An environment switch can disable the scheduled work.

The host also stops the controller during agent release, backend stop, and close. The controller waits for any pending pass before its stop call resolves and avoids starting new stages once stopped. This matters for an execution backend that can hand work to another generation: cleanup should be tied to the owner that has the current view of active work. The sequencing in the committed code shows how that ownership is intended to work, without proving every possible handoff outcome.

Journals store less display data

The event journal gained an encoder for two kinds of display block events. Small entries and other event kinds remain ordinary JSON lines. For an eligible entry of at least 2,048 bytes, the encoder compresses the block with raw DEFLATE and uses the encoded representation only if it is shorter than the plain entry. It can also store a compressed splice against an earlier block with the same event identity when that representation is smaller. The in-memory history used for these comparisons is bounded by byte count, entry count, and chain depth.

This is a storage format change, not a change to the event delivered to a connected client. The backend still sends the original entry on its live connection. During replay, it reads journal offsets, decodes stored blocks, and returns reconstructed events. Replay page accounting uses the original entry length rather than the compressed length. The decoder checks the encoding, output size, reference cursor, and splice boundaries before reconstructing a block. Lifecycle and process events are left in plain JSON in the journal, which keeps those records directly inspectable by exchange verification.