Journal

· guides

A launch smoke cannot prove a service serves

Muniment Desktop kept four launch smokes green while its background service wrote one record and exited without serving.

Three launch checks lead through a service mechanism and one record to a verdigris handshake endpoint trace.

A green launch proves that an app launched. Our Muniment Desktop record shows why service evidence must request the interface that users depend on.

Muniment Desktop ships a desktop app with a per-user background service. Its installed smoke on one platform checked four things:

  1. Install the bundle.
  2. Launch the app.
  3. Count its windows.
  4. Capture a screenshot.

Muniment Desktop passed those steps every night for four days while its background service served nothing.

One record looked enough like a start

A Muniment Desktop refactor broke the service binary’s compile on that platform. The repair restored compilation by recording a failed activation and exiting.

Muniment Desktop left the real serving path for a follow-up. For four days, each nightly installed a bundle whose service started, wrote one record, and exited.

Muniment Desktop then fell back to degraded local behavior. Its smoke still saw the app launch and its windows appear, so the lane stayed green.

A saved settings change also applied nothing. Muniment Desktop applies that change through a schedule inside the service, which never stayed up to run it.

Request the contract instead of the process

Muniment Desktop closed the gap with a served-endpoint probe. Its smoke now requests the service handshake and fails when no endpoint answers.

A process start reports an event. A request and response exercise the boundary that gives the service a purpose.

This distinction sounds obvious when testing a web service. Request a route instead of checking that its daemon runs. A smoke scoped around application launch can still miss it.

A handshake leaves deeper work unproved

Muniment Desktop’s probe checks the handshake alone. A service could answer that request, fail a deeper operation, and still pass the installed smoke.

Muniment Desktop’s unit and integration tests cover those deeper operations. Its installed lane keeps the narrower job of proving that the packaged service answers its served interface.

Four green days hid a service that exited at start. One endpoint request made the lane test service rather than its outline.

Continue reading

All publications

Join the waitlist

Get desktop release updates.

We will email you about desktop releases and new features. muniment is a desktop workspace for your models, tools, and files.