Expose StreamingPullManager.load property via StreamingPullFuture

[vladkol]

Is your feature request related to a problem? Please describe.
When implementing custom scaling mechanisms in worker-pool workloads, the only current working solution is to count active messages. This is cumbersome and also doesn't account for other reasons why a particular worker may be close to its limits. Using monitoring metrics is not always feasible and imposes longer aggregation periods.

Describe the solution you'd like
A public property on StreamingPullFutire that provides read-only getter to __manager.load

Describe alternatives you've considered
Counting total active messages and their cumulative size manually in code.

[abbrowne126]

Hi @vladkol, can you share a little more about your use case? In general, I think we are disinclined to expose this property for a few reasons:

• The load property is essentially an implementation detail from an internal class that we may want to change in the future. We currently do indeed use it as a sort of fullness measure in the range [0,1], but there have been discussions about changing this. Exposing this publicly limits our ability to make these changes.
• We like to keep these kinds of API changes consistent across languages. Exposing this at all, and especially through a streaming pull future, could run counter to that.
• I don't think the streaming pull future is the right place to hypothetically expose a property like this - it's really only intended to control the stream lifetime (listen for completion, cancel, etc).

Overall, we have some scaling recommendations here including some recommendations about autoscaling in GKE with CPU utilization as a signal. Scaling at the level of a client is generally not as robust as scaling across the metrics available for the subscription as a whole.

We recommend most of all to use backlog metrics, but I understand that monitoring metrics have some limitations with scaling that may complicate this for you.