What happens if this errors? I don't see a catch, so I'm not sure how we'd enter the error state on line 157 of this machine. I would want to avoid prompting users to restart their workspace if no change was actually made.

I wasn't sure if it was a problem that I'm not returning the result from both promises here, so I tried hard-coding each api call to return a rejected promise, and it behaved the way I intended: if one api call errors and that part of the schedule is not changed, there's no error. If the error api call is called, you stay on the form and get an error message. If you change the start but not the stop, you don't see the prompt.

Permissions are loaded in the initial app loading in the auth machine so I don't think we need to load it again. If there are new permissions, I would add them there.

I would do is something like this:

const permissions = usePermissions()
const [workspaceScheduleState] = useMachine(workspaceSchedule, { context: { permissions } })

Okay, I didn't add the permissions stuff in this PR (the machine just got reformatted), but I'll make a note to look into that later.

Maybe, we could condense the gettingPermissions, gettingWorkspace, and gettingTemplate in a single state called loading + a load service that returns all this info. I'm thinking we are over-creating states making the machine more complex to understand without a clear value. By over-creating, I mean states that are not reflected in the UI/UX.

Yeah, on one hand having separate states is helpful for debugging, but on the other hand it's extra states that aren't strictly necessary. We could change the way we handle errors to save whichever error we get going through the whole loading sequence. I'm not going to hold up this PR over it but it's worth considering in the future.