Replace returnImmediately with a timeout
In its current form,
projects.subscriptions.pull accepts the following parameters in its request payload:
maxMessages. The former parameter restricts the library authors (including the official GCP driver) into one of two extremes:
Either poll the endpoint periodically (e.g., every 10s) via
Or poll indefinitely via
The first approach ensures a deterministic message stream with the cost of degraded latency. The second approach does the opposite: a nondeterministic stream with better latency. I think there is a better alternative: introducing a timeout parameter. This will act as knob one can tune to move between these two extremes. Here the aforementioned two approaches then will correspond to timeout=0 and timeout=-1, respectively. Further, one will be able to pick a state providing the best of both worlds, e.g., timeout=5m.
Note that timeout parameter can be introduced in a backward compatible fashion, hence existing users will not get affected. After a certain period, returnImmediately can be entirely dropped.
Kamal Aboul-Hosn commented
One can already set a timeout on the underlying gRPC or HTTP request that is sent when using synchronous pull. It shouldn't be necessary to make a timeout a part of the API itself.