pubsub: publish error that requires ResumePublish should wrap and return a specific exported error

[ramirezalbert3]

Is your feature request related to a problem? Please describe.

When publishing with an ordering key you may end up in a situation where you're required to ResumePublish because the scheduler was paused. This would be much easier to detect and handle if instead of:

err = fmt.Errorf("pubsub: Publishing for ordering key, %s, paused due to previous error. Call topic.ResumePublish(orderingKey) before resuming publishing", orderingKey)

we had something like:

// first
var ErrPublishingPaused = errors.New("Call topic.ResumePublish(orderingKey) before resuming publishing")
// and then
err = fmt.Errorf("pubsub: Publishing for ordering key, %s, paused due to previous error. %w", orderingKey, ErrPublishingPaused)

Describe the solution you'd like
In the example above I believe there's a good enough, fully backwards compatible and idiomatic solution. Similar implementations could be proposed that don't rely on errors.New if needed.

[hongalex]

This would be much easier to detect and handle

Could you elaborate more on why you need the distinction between the first or subsequent failures for ordering keys?

fully backwards compatible

I have a concern that since we are changing the error message here, it's not entirely backwards compatible. Ideally, users should not be doing error string comparisons, but since error wrapping was introduced in a Go version that wasn't supported when this bit was written, I suspect that might be what's happening. Might still be worth doing, but would require more specific justification.

[ramirezalbert3]

Sorry maybe I didn't explain myself properly, what we'd need is for a way to be able to distinguish this error situation that requires calling ResumePublish from other errors that may not require it? Example here: https://cloud.google.com/pubsub/docs/samples/pubsub-resume-publish-with-ordering-keys

About backwards compatibility, fully agree that should be done preserving the same string representation, i tried to go for it with my example?

[hongalex]

Ah gotcha, I think I misunderstood to thinking you wanted different error messages for the first occurrence of a failed ordering message.

Adding a well defined (wrapped) error shouldn't be breaking and should be fine. I can throw together a PR for this. Thanks for the suggestion!