[filebeat][streaming] - Added default values for websocket retries & …

…put a cap on waitTime to be <= waitMax (#42012)

* added default retry values and ensured a cap on waitTime i.e now waitTime <= wait_max

* updated changelog

CHANGELOG.next.asciidoc

@@ -368,6 +368,7 @@ https://github.com/elastic/beats/compare/v8.8.1\...main[Check the HEAD diff]
 - AWS S3 input registry cleanup for untracked s3 objects. {pull}41694[41694]
 - The environment variable `BEATS_AZURE_EVENTHUB_INPUT_TRACING_ENABLED: true` enables internal logs tracer for the azure-eventhub input. {issue}41931[41931] {pull}41932[41932]
 - Rate limiting operability improvements in the Okta provider of the Entity Analytics input. {issue}40106[40106] {pull}41977[41977]
+- Added default values in the streaming input for websocket retries and put a cap on retry wait time to be lesser than equal to the maximum defined wait time. {pull}42012[42012]
 
 *Auditbeat*
 

x-pack/filebeat/docs/inputs/input-streaming.asciidoc

@@ -337,17 +337,17 @@ filebeat.inputs:
 [float]
 ==== `retry.max_attempts`
 
-The maximum number of times the input should attempt to reconnect to the streaming data source in the event of a connection failure. The default value is `nil` which means no retries will be attempted.
+The maximum number of times the input should attempt to reconnect to the streaming data source in the event of a connection failure. The default value is `5` which means a maximum of 5 retries will be attempted.
 
 [float]
 ==== `retry.wait_min`
 
-The minimum time to wait between retries. This ensures that retries are spaced out enough to give the system time to recover or resolve transient issues, rather than bombarding the system with rapid retries. For example, `wait_min` might be set to 1 second, meaning that even if the calculated backoff is less than this, the client will wait at least 1 second before retrying.
+The minimum time to wait between retries. This ensures that retries are spaced out enough to give the system time to recover or resolve transient issues, rather than bombarding the system with rapid retries. For example, `wait_min` might be set to 1 second, meaning that even if the calculated backoff is less than this, the client will wait at least 1 second before retrying. The default value is `1` second.
 
 [float]
 ==== `retry.wait_max`
 
-The maximum time to wait between retries. This prevents the retry mechanism from becoming too slow, ensuring that the client does not wait indefinitely between retries. This is crucial in systems where timeouts or user experience are critical. For example, `wait_max` might be set to 10 seconds, meaning that even if the calculated backoff is greater than this, the client will wait at most 10 seconds before retrying.
+The maximum time to wait between retries. This prevents the retry mechanism from becoming too slow, ensuring that the client does not wait indefinitely between retries. This is crucial in systems where timeouts or user experience are critical. For example, `wait_max` might be set to 10 seconds, meaning that even if the calculated backoff is greater than this, the client will wait at most 10 seconds before retrying. The default value is `30` seconds.
 
 [float]
 === `timeout`

x-pack/filebeat/input/streaming/config.go

@@ -171,5 +171,10 @@ func defaultConfig() config {
 		Transport: httpcommon.HTTPTransportSettings{
 			Timeout: 180 * time.Second,
 		},
+		Retry: &retry{
+			MaxAttempts: 5,
+			WaitMin:     1 * time.Second,
+			WaitMax:     30 * time.Second,
+		},
 	}
 }

x-pack/filebeat/input/streaming/websocket.go

@@ -261,6 +261,10 @@ func calculateWaitTime(waitMin, waitMax time.Duration, attempt int) time.Duratio
 	jitter := rand.Float64() * maxJitter
 
 	waitTime := time.Duration(backoff + jitter)
+	// caps the wait time to the maximum wait time
+	if waitTime > waitMax {
+		waitTime = waitMax
+	}
 
 	return waitTime
 }