Application Lifecycle

This module defines some generic lifecycle utilities users can implement for themselves. Both Clients and Services can use these utilities, but they should be considered optional.

It IS essential for an application to be able to shut down gracefully, as the adapter can communicate to the broader INTERSECT ecosystem that they have shut down. Obviously, not all shutdowns can be detected.

However - classes and functions in this module are not essential towards an adapter functioning properly. If you’re using something with its own lifecycle, you can safely ignore this module and implement the calls to the adapter lifecycle functions yourself.

For example, it’s possible to integrate an INTERSECT adapter with a FastAPI web server. Since FastAPI already manages its own lifecycles, you should integrate your adapter with FastAPI manually, and let FastAPI handle lifecycles.

class intersect_sdk.app_lifecycle.SignalHandler(cleanup_callback: Callable[[int], None] | None = None)

Listen for signals sent to process and try to clean up gracefully.

Once the constructor has been initialized, signals will be caught.

We catch the following signals, based on platform support:

  • SIGINT (same as Ctrl+C)

  • SIGTERM

  • SIGHUP

  • SIGQUIT

  • SIGUSR1

  • SIGUSR2

Currently, we do not ignore any signals we catch, though debatably SIGHUP (terminal died), SIGQUIT (core dump), SIGUSR1, and SIGUSR2 should be ignored.

should_stop() → bool

Determine if signal has been detected. Useful as the “while” condition for application loops.

Returns: True if signal has been detected, False otherwise

stop() → None

Manually stop this SignalHandler, without actually sending the OS signal.

wait(amount: float) → None

While a signal has not been called, block for “amount” seconds.

If a signal is caught, the “wait” function is immediately interrupted.

Params:

amount: time to block

intersect_sdk.app_lifecycle.default_intersect_lifecycle_loop(intersect_gateway: IntersectClient | IntersectService, delay: float = 30.0, post_startup_callback: Callable[[], None] | None = None, cleanup_callback: Callable[[int], None] | None = None, waiting_callback: Callable[[IntersectClient | IntersectService], None] | None = None) → None

If users don’t have their own lifecycle manager, they can import this function to begin a lifecycle loop.

This loop automatically catches appropriate OS signals and allows for graceful shutdown.

IMPORTANT: If you are integrating an INTERSECT adapter into your existing application, you should use your own application’s lifecycle manager instead.

Params:

  • intersect_gateway: This can be either an IntersectClient or an IntersectService.

  • delay: how often the loop should wait for (default: 30 seconds)

  • post_startup_callback: Optional callback function which is called after service startup, once. The callback function provides no parameters. This can be useful if you want to start up some event-emitting threads inside your capability, which you should only do AFTER you’ve connected to the brokers.

  • cleanup_callback: This is an optional callback function which will be called once a signal is caught. The callback function takes in a single integer parameter, which will be the signal code intercepted. The function will be executed just before the loop ends.

  • waiting_callback: This is an optional callback function which will be called every <DELAY> seconds. It takes in the adapter, and returns nothing. This can be useful to set for debugging purposes.