Fetch timeout

[bmatthews]

Hi, on a pull subscriber what are the positives and negatives of a larger timeout? e.g

	ctx, cancel := context.WithTimeout(ctx, 30*time.Second)
	defer cancel()

	msgs, err := sub.Fetch(10, nats.Context(ctx))

In my use case i am simply polling over fetch so if it times out then i call it again anyway.

[aricart]

Depending on your network topology the JetStream you talk to may not be the one that you are directly connected to. If for some reason the server handling your request is partitioned/etc.
This means that your client may hang waiting for messages until the expiration timer on the client kicks in. If you have a shorter expiration (the 30s is possibly a good expires setting), the client would possibly recover faster (assuming the server came back up).

If the service is unavailable when you re-pull, you would be alerted with a 503 (no responders/timeout).

A recent PR on the server allows for heartbeats with pull consumers, but this is not yet implemented by the clients.

[bmatthews]

thanks for the info @aricart that makes sense 👍