...

1. There might be multiple instances of a rhythm service, but only one event should be sent. (Currently, this use case is prepared for, but not completely implemented.)
2. Unlike most other services, the tenant is not part of the request which causes an action to be started.  Only the time of day is.  For this reason, the beat specifications cannot be saved in a tenant-specific table.  Since we don't want to set up one rhythm service per tenant, internally there must be one table for all tenants.
3. Calls to the other services should be made in a secure fashion.  The "beat" is clock-initiated not user-initiated.  A user token cannot be used to authorize the action.

Troubleshooting

If you are having trouble with rhythm, please check the following aspects of  your deployment:

There should be only one instance of rhythm running.

In the configuration, rhythm.user should be set to a valid user in your system.  I'll pretend you named it imhotep for the rest of examples in this document.

Rhythm the application should have permission to act in the name of its user to access the identity endpoint for creating permission requests for other services. /applications/rhythm/permissions/identity__v1__app_self/users/imhotep/enabled should return true

Rhythm's user should have permission to the identity endpoint for creating permission requests for other services, and for the application which is to receive the beats. Its role should contain change permissions for identity__v1__app_self, and for example portfolio__v1__khepri