Stopping and errors

Request an orderly stop

Call stop() after execution has started. It requests an orderly unwind. Await the promise returned by run() to receive the final result:

TypeScript

const execution = service.run();

process.once('SIGTERM', () => {
	service.stop();
});

const result = await execution;
process.exitCode = result.exitCode;

Rust

use microde_microservice::MicroserviceStopRequest;

let execution = service.run();
service.stop(MicroserviceStopRequest::success());
let result = execution.await?;
assert_eq!(result.exit_code, 0);

You can request a particular exit code, associate an error with the stop, or provide both:

TypeScript

service.stop(2);
service.stop(new Error('lost connection'));
service.stop(2, new Error('invalid configuration'));

Rust

service.stop(MicroserviceStopRequest::with_exit_code(2));
service.stop(MicroserviceStopRequest::with_error(
    MicroserviceError::new("lost connection"),
));
service.stop(MicroserviceStopRequest::with_exit_code_and_error(
    2,
    MicroserviceError::new("invalid configuration"),
));

Only the first stop request supplies the requested exit code and error. Calling stop() before the service starts throws.

Every orderly trigger joins the same unwind path. Multiple callers waiting on run() or Rust's stop() receive the same completed result.

Handle lifecycle failures

Lifecycle failures do not reject the main execution promise. Inspect the returned result after cleanup finishes:

TypeScript

const result = await service.run();

if (result.errors) {
	for (const error of result.errors) {
		console.error(error);
	}
} else if (result.error !== undefined) {
	console.error(result.error);
}

Rust

let result = service.run().await?;

if let Some(errors) = result.errors {
    for error in errors {
        eprintln!("{error}");
    }
} else if let Some(error) = result.error {
    eprintln!("{error}");
}

The errors array is present only when more than one failure was recorded. error contains the primary failure.

Panic only when immediate exit is required

panic(error) logs the error and a trace, then calls process.exit(1). Because this bypasses teardown and cleanup, reserve it for conditions where continuing the normal lifecycle is unsafe.