Skip flaky test TestSQSReceiver/ReceiveMessage_success

[belimawr]

Proposed commit message

See title

Checklist

• My code follows the style guidelines of this project
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have made corresponding change to the default configuration files
• I have added tests that prove my fix is effective or that my feature works
• I have added an entry in CHANGELOG.next.asciidoc or CHANGELOG-developer.next.asciidoc.

## Disruptive User Impact
## Author's Checklist
## How to test this PR locally

Related issues

• Flaky test: [Flaky test] TestSQSReceiver - missing call(s) to *awss3.MockSQSAPI.ReceiveMessage #41458

## Use cases
## Screenshots
## Logs

[elasticmachine]

Pinging @elastic/elastic-agent-data-plane (Team:Elastic-Agent-Data-Plane)

[mergify]

This pull request does not have a backport label.
If this is a bug or security fix, could you label this PR @belimawr? 🙏.
For such, you'll need to label your PR with:

• The upcoming major version of the Elastic Stack
• The upcoming minor version of the Elastic Stack (if you're not pushing a breaking change)

To fixup this pull request, you need to add the backport labels for the needed
branches, such as:

• backport-8./d is the label to automatically backport to the 8./d branch. /d is the digit

[mergify]

backport-8.x has been added to help with the transition to the new branch 8.x.
If you don't need it please use backport-skip label and remove the backport-8.x label.

[jlind23]

@bturquet can we get someone from your team to review this?

[Kavindu-Dodan]

@bturquet can we get someone from your team to review this?

I had a look into the failing test and the logic it's testing. IMO, this test is important as it validates SQS processing from end to end with mocked processors. So we should not disable this test.

The flakiness comes from this gomock stub ¹. And the root cause seems to be,

• We perform a context cancel to exit the processing and test once we complete SQS message processing and register a call to DeleteMessage ²
• This ctx cancellation has a race condition with readSQSMessages ³ which internally calls ReceiveMessage

I think we can fix the flakiness by simply changing Times(1) to AnyTimes() ⁴. This allows us to have zero or more calls to the read messages.

Footnotes

1. https://github.com/elastic/beats/blob/v8.17.0/x-pack/filebeat/input/awss3/sqs_test.go#L59-L63 ↩

2. https://github.com/elastic/beats/blob/v8.17.0/x-pack/filebeat/input/awss3/sqs_test.go#L75 ↩

3. https://github.com/elastic/beats/blob/v8.17.0/x-pack/filebeat/input/awss3/sqs_input.go#L160C11-L160C26 ↩

4. https://github.com/elastic/beats/blob/v8.17.0/x-pack/filebeat/input/awss3/sqs_test.go#L61 ↩

[Kavindu-Dodan]

Shall we enable the test again and go with the the proposed change of this comment - #42245 (comment) ?

[belimawr]

Shall we enable the test again and go with the the proposed change of this comment - #42245 (comment) ?

From the data-plane perspective, as long as the test is not flaky/is blocking CI, I don't see any issues in re-enabling it.

However, the solution you suggested seems to fix the symptom, not the root cause. I believe a better fix would be to fix the race condition. I don't know the internals of this input here, so I might be wrong 🙈

Anyways, feel free to open a PR with the fix you believe it's best and removing the t.Skip.