OSX 10.12.1v7.0.03.10.80.44.2The PubSub component appears to decorate messages with convenience methods ack() and skip(), as it additionally explains here in the docs.
As far as I can tell, the skip() method only frees up slots as far as maxInProgress goes, allowing the user to pull one more message for each message skipped. Although that does make sense (at minimum), wouldn't it additionally make sense to invoke (or at least provide as opt-in behavior) setAckDeadline with a 0-value in service of making the message available for immediate reprocessing on subsequent pulls?
Of course, I can do this manually. But intuitively, I'd expect that that's one of the main use cases (to the extent that I almost wonder if it should be a default) when skipping over messages as part of a pull call.
Specifically, for my use case, I'm iterating over all messages on a given subscription looking for a particular message. The respective message that I'm looking for comes from an external actor in the form of a "reprocess entity X" event, and can happen at any time within the 7-day max-lifespan of a message, and in any order (as far as all of the messages on the subscription go).
As I'm iterating through, and looking for a particular message, I generally pull some quantity N at a time, and at most one is the message in question. In other words, for some non-zero quantity N, there's either N or N-1 messages that I'm not interested in and correspondingly skip over. Just invoking skip() however doesn't release the message for reprocessing (again, as far as I can tell), whether for the same process or for other peer processes, until the ack window is up (eg. 10 seconds).
Accordingly, I'm proposing that there be an equally convenient way of explicitly releasing control of a message at the actual message level (similar to how you'd ack a message), whether as the default behavior of skip() or as some sort of optional behavior! 馃槃
I think this idea makes a lot of sense! As far as implementation, I'm thinking something like:
message.skip = function(callback) {
message.setAckDeadline({
ackIds: [message.ackId],
seconds: 0
}, callback || noop)
}
Does that work? It would always try to set the deadline to 0. The user can send a callback to receive any errors, or just assume it worked successfully / not care because the default ack deadline will eventually free it anyway.
That's pretty much exactly what I had in mind! 馃憣 馃帀
I'll mark with help wanted in case anyone is crazy enough to send a PR :)
We're about to have a pretty big overhaul to the Pub/Sub API. This feature will not be implemented as originally planned. Please stay tuned for the PR / release of the new API.