It seems like a reasonably workflow that this check could get run if an email was put on-hold previously from the CiviCRM side, but the email was not on the Sparkpost suppression list, and gets taken off-hold by a user-submitted form or something like that. In this case we wouldn't want to show the user an error message.
This PR adds a check for a valid code and response from Sparkpost before throwing a generic error to avoid showing users blank errors for expected workflows.
Behavior is documented in the issue: Users see a blank error message for a 404 response. It looks like this happens if CiviCRM tries to delete the email on the suppression list but it's not on the suppression list and the 404 is an expected response (see https://developers.sparkpost.com/api/suppression-list/#suppression-list-get-retrieve-a-suppression).
It seems like a reasonably workflow that this check could get run if an email was put on-hold previously from the CiviCRM side, but the email was not on the Sparkpost suppression list, and gets taken off-hold by a user-submitted form or something like that. In this case we wouldn't want to show the user an error message.
This PR adds a check for a valid code and response from Sparkpost before throwing a generic error to avoid showing users blank errors for expected workflows.