Foxx in a cluster setup

    The same considerations that apply to writing Foxx services for a standalone server also apply to writing services for a cluster:

    You should avoid any kind of file system state beyond the deployed service bundle itself. Don’t write data to the file system or encode any expectations of the file system state other than the files in the service folder that were installed as part of the service (e.g. don’t use file uploads or custom log files).

    Additionally, special precautions need to be taken when using the .

    1. When installing, upgrading or replacing a service, the new service is extracted to a temporary directory where Foxx validates the manifest file and parses the referenced scripts and main file.

    2. When replacing, upgrading or installing a service, the new service’s setup script is executed in a single thread of the Coordinator as desired.

    3. The existing service is unloaded from the Coordinator’s worker threads and the new service is reloaded. If the new service runs into an error at this point, the service will be marked as broken and needs to be replaced manually.

    4. The Coordinator triggers a local self-heal followed by triggering a self-heal on all other Coordinators.

    Note that this means that any service that passes the initial validation step will complete the install, upgrade or replace process, even if any of the consecutive steps fail (e.g. due to a runtime error encountered while executing the service’s main file or a syntax error in a required file not referenced from the manifest directly).