Correspondence Regarding Temporary Timeout Increase

To: The team From: The developer who raised the timeout Subject: RE: RE: RE: Timeout value for the thing

Following up on the thread below.

The timeout was raised last Tuesday to 120 seconds from 30 seconds. The failures stopped. The root cause was not investigated. The intent was to investigate the root cause after the immediate pressure reduced. The pressure reduced. The investigation did not happen.

This is not an unusual sequence of events.

To: The developer who raised the timeout From: The developer who added the next feature Subject: RE: RE: RE: RE: Timeout value for the thing

I saw the 120s value and assumed it was correct. I wrote the next integration to the same value. It has been running at 120s for six weeks.

I do not know why 120s was the original choice. I have assumed there is a reason.

To: The team From: The developer who raised the timeout Subject: RE: RE: RE: RE: RE: Timeout value for the thing

There was a reason. The reason was that 30s was failing. The new reason is that 120s has been in place for six weeks and anything I change it to now will require testing that the deadline does not permit.

Any repeated case of temporary timeout increase becomes standard procedure until someone deliberately replaces it. Nobody has filed that replacement. The 120s value is now the default.

To: The developer who raised the timeout From: A new team member Subject: RE: RE: RE: RE: RE: RE: Timeout value for the thing

What should I set for the timeout in my service?

To: A new team member From: The developer who raised the timeout Subject: RE: RE: RE: RE: RE: RE: RE: Timeout value for the thing

Use 120s.

The workaround reduces immediate risk while quietly increasing the amount of context future work will require. After enough repeats, the workaround survives even when the original inconvenience is gone. We are past that point.

The root cause is still there.

Closing this thread. Please open a new one if the failures return.