We should capture the state of whether we've ever successfully finished the processing loop in the processing submachine in the machine context, and use that context in every onError handler (or on the special fetchError state, also the onDone handler) to split how we handle:
- Errors during initial processing should STOP the entire party machine, as they do now.
- Errors during refetch should be reported, and force the processing machine back to
idle state.
- The report should be as an ephemeral reply to the interaction to let the compo admin know that the refetch failed and the party may be in a bad state, and that they must refetch again.
Generally for messaging, errors should be reported both to the channel similar to the form they are now: just reporting that there is a general issue with the party, as well as using the debug logging to send to both the console as well as the debug channel & sending an ephemeral reply to the interaction to let the compo admin know they should check the debug channel for more info on what error occurred.
Possibly as part of this, if the streaming submachine moves to the playingSong state, we should guard that the song is in the ready state. If it is not, we move to a new state called currentSongNotReady which will invoke sending a message to the channel that the song will be skipped because there was an error processing it (naming it and the artist, etc), and then move to the pickNextSong state.
We should capture the state of whether we've ever successfully finished the processing loop in the
processingsubmachine in the machine context, and use that context in everyonErrorhandler (or on the specialfetchErrorstate, also theonDonehandler) to split how we handle:idlestate.Generally for messaging, errors should be reported both to the channel similar to the form they are now: just reporting that there is a general issue with the party, as well as using the debug logging to send to both the console as well as the debug channel & sending an ephemeral reply to the interaction to let the compo admin know they should check the debug channel for more info on what error occurred.
Possibly as part of this, if the streaming submachine moves to the
playingSongstate, we should guard that the song is in thereadystate. If it is not, we move to a new state calledcurrentSongNotReadywhich will invoke sending a message to the channel that the song will be skipped because there was an error processing it (naming it and the artist, etc), and then move to thepickNextSongstate.