Stop Timeout While Waiting for Response

[sburmanoctopus]

[sc-59506]

Background

It was noticed that PollingRequestMaximumMessageProcessingTimeout was redundant.

PollingRequestMaximumMessageProcessingTimeout is the amount of time we will wait for a response to be given from a request that has already been dequeued.

The down side of keeping PollingRequestMaximumMessageProcessingTimeout is that it will also timeout an operation that is successful, but taking a long time (e.g. downloading a large package to a Tentacle, or over a slow network, complex script/action for Tentacle to run etc.).

We think it was added years ago as a way to ensure we do not wait forever if communications with the Tentacle dies.

But we believe this won't be an issue because:

• We always make sure a response is set, regardless of success or failure. Applying a response stops us waiting
• We have timeouts and keep alives applied to the TCP connection. So if we loose communications with the Tentacle, these mechanisms will be what fail and stop us from waiting forever.
• Web sockets recently was enhanced to time out. So there should be no other types of polling tentacle that wait forever.

Results

Related to OctopusDeploy/Issues#8229

Before

No matter why it took a long time to complete a task, we would always timeout after PollingRequestMaximumMessageProcessingTimeout

After

We now simply wait until a response is applied, and rely on the communication timeouts and response applying to break the waiting.

How to review this PR

Quality :heavy_check_mark:

Pre-requisites

• [ ] I have read How we use GitHub Issues for help deciding when and where it's appropriate to make an issue.
• [ ] I have considered informing or consulting the right people, according to the ownership map.
• [ ] I have considered appropriate testing for my change.

[shortcut-integration[bot]]

This pull request has been linked to Shortcut Story #59506: Decouple the Polling Response Timeout from the duration it takes to transfer a request and response.