Hi Temporal team!
First of all - thank you for building Schedules, love how this new feature separates the concern of a “schedule” from the workflow. It looks both more powerful and easier to use than cron workflows.
In our case, we’re using application code (instead of Temporal CLI) to manage schedules. Specifically, every time an application that “owns” a schedule is deployed, it makes sure that the schedule definition in Temporal matches what is defined in the app’s configuration.
To do that, we’re using a helper method like this one
fun WorkflowServiceBlockingStub.applySchedule(
namespace: String,
scheduleId: String,
schedule: Schedule?,
) {
if (schedule != null) {
try {
updateSchedule {
this.namespace = namespace
this.scheduleId = scheduleId
this.requestId = UUID.randomUUID().toString()
this.schedule = schedule
}
logger.info { "Updated Temporal schedule $schedule in namespace $namespace" }
} catch (e: StatusRuntimeException) {
if (e.status.code == Status.Code.NOT_FOUND) {
createSchedule {
this.namespace = namespace
this.scheduleId = scheduleId
this.requestId = UUID.randomUUID().toString()
this.schedule = schedule
}
logger.info { "Created Temporal schedule $scheduleId in namespace $namespace" }
} else {
logger.warn(e) { "Failed to update Temporal schedule $scheduleId in namespace $namespace" }
}
}
} else {
try {
deleteSchedule {
this.namespace = namespace
this.scheduleId = scheduleId
}
logger.info { "Deleted Temporal schedule $scheduleId in namespace $namespace" }
} catch (e: StatusRuntimeException) {
if (e.status.code != Status.Code.NOT_FOUND) {
logger.warn(e) { "Failed to delete Temporal schedule $scheduleId in namespace $namespace" }
}
}
}
}
So basically, either try to update the existing schedule, and if that fails, create a new one, or delete a schedule.
The code looks generic enough, so I wonder if this is something you might accept as a contribution, either as an SDK feature or maybe even as a dedicated GRPC call?