> The first obvious reason for stopping is to send the hub an > unsubscribe request. The second reason I'd say (as has been talked > about on another thread on this list) is for the subscriber's callback > URL to start returning an error status. From the point of view of the > hub I'd consider anything that is >= 300 an error and reason to > suspend the callback URL. > > This discussion so far has focused on the hub's responsibilities, but > there are related issues on the callback end as well. If the callback > URL suddenly starts returning 403 Forbidden during some 30 minute > interval (could be anything pulled that out of the air) then I think > it's up to that client to send new subscription requests, knowing that > the hub might have suspended it's subscriptions.
I disagree with this approach of unsubscribing a callback after 30 minutes of delivery failures. The concrete situation I'm concerned about is when a broken/misconfigured frontend (like nginx) starts returning 502s for some period of time, causing a percentage of requests to fail. I think hubs should drop delivery requests to this callback URL/domain during this period of errors (so there's no harm to the hub), but they should not unsubscribe the callback. Instead, after seeing a high error rate for the callback, the hub should mark this subscription to be auto-refreshed soon in the future (say 1-6 hours ahead). Then the hub should use the auto-refresh logic (with backoff and retries) to cause the subscription to be double-checked and then unsubscribed. The benefits of this approach are: 1. It weathers any temporary issues with the callback URL. 2. It's consistent, meaning unsubscribes will *only* happen after verification requests have been attempted and failed after a number of retries. 3. Because #2 requires double-checking on unsubscribe, you can configure your frontend's GET and POST handlers to go to different backend servers. The subscription pieces are much lower throughput and have a higher chance of being successfully reachable, thus you may be returning 502s/503s on callback delivery but still return success for subscription verification. I worry that the alternative to these details is having subscribers that are overly paranoid and send subscription requests to hubs every hour or so just to be sure they're always subscribed. I hope that makes sense! -Brett
