Environment details
- OS:
OSX 10.12.1
- Node.js version:
v7.0.0
- npm version:
3.10.8
- google-cloud-node version:
0.44.2
Explanation
The 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! 😄
Environment details
OSX 10.12.1v7.0.03.10.80.44.2Explanation
The PubSub component appears to decorate messages with convenience methods
ack()andskip(), as it additionally explains here in the docs.As far as I can tell, the
skip()method only frees up slots as far asmaxInProgressgoes, 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
pullcall.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
Nat 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 invokingskip()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
acka message), whether as the default behavior ofskip()or as some sort of optional behavior! 😄