Right now, registering a task type in the scheduler requires a manual insert request in the database of the scheduler. This is problematic because it makes local testing pretty hard. You need to import the task types from the production database, there aren't any default values that can be used easily. This is especially hard for newcomers that don't necessarily have access to the production database: they have to reverse-engineer the different task types and a useful default configuration, as we have no way to provide some default configuration for these tasks.
The proposed solution would be to have the workers automatically register the tasks they are able to execute with some default configuration/policy with sane defaults that are stored in the code.
When a worker starts, it will do an RPC request to the scheduler to say that it's able to execute a task with a given name, and will give its local default configuration. If the scheduler doesn't already have this task registered, it will register it with the given configuration, else it will just return the current configuration.
After the return of the RPC call, if the configuration returned by the scheduler doesn't match the configuration that was sent to it for the registration, we will issue a warning that the configuration "in code" doesn't match the one in database, and that a manual intervention is required. This is to avoid getting too much out of sync between the code and the default configuration, that should eventually tend to match.
This automatic registration allows us to keep the flexibility of being able to edit the policies of tasks that have already been registered without restarting the services, while allowing a "drop-in" scheduling mechanism that will make life of newcomers easier and writing new services much more elegant.