Skip to content

Make streams test compatible with chicken test#823

Merged
gbanasiak merged 8 commits intoelastic:masterfrom
flash1293:test-fix
Jul 22, 2025
Merged

Make streams test compatible with chicken test#823
gbanasiak merged 8 commits intoelastic:masterfrom
flash1293:test-fix

Conversation

@flash1293
Copy link
Contributor

Make sure the logs stream works with the mapped = "unmapped" parameter. This isn't the case right now because all other data streams are captured by the default logs-*-* mappings, but logs is not.

@flash1293
Copy link
Contributor Author

@gbanasiak This fails unit tests because you can't run with and without mapped=unmapped on the same cluster. The next test is cleaning up for the previous, but the test with mapped=unmapped will be aware of a different set of templates.

However, it would be nice to test it somehow - what I can think of is to move it to the very first position, but that's definitely brittle. Do you have a better idea?

I didn't test this, but I wonder whether we even need to exclude all the individual per-dataset templates for the unmapped test, instead of just bumping up the priority in ./templates/composable/logs-dynamic-false.json so it will overrule all the others...

@flash1293
Copy link
Contributor Author

Testing this with 9e56387

@flash1293
Copy link
Contributor Author

Kind of obvious in hindsight, but this has the same issue in the other direction... Not sure what the least hacky solution for this would be - any thoughts, @gbanasiak ?

@gbanasiak
Copy link
Contributor

The next test is cleaning up for the previous, but the test with mapped=unmapped will be aware of a different set of templates.

facepalm! Of course... Well, we can move tests that absolutely require it to a new ES cluster. Let me add it here.

Copy link
Contributor

@gbanasiak gbanasiak left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@gbanasiak gbanasiak merged commit e5f07e4 into elastic:master Jul 22, 2025
13 checks passed
@esbenchmachine esbenchmachine added the backport pending Awaiting backport to stable release branch label Dec 19, 2025
@esbenchmachine
Copy link
Collaborator

@flash1293
A backport is pending for this PR. Please add all required vX.Y version labels.

  • If it is intended for the current Elasticsearch release version, apply the corresponding version label.
  • If it also supports past released versions, add those labels too.
  • If it only targets a future version, wait until that version label exists and then add it.
    (Each rally-tracks version label is created during the feature freeze of a new Elasticsearch branch).

Backporting entails:

  1. Ensure the correct version labels exist in this PR.
  2. Ensure backport PRs have backport label and are passing tests.
  3. Merge backport PRs (you can approve yourself and enable auto-merge).
  4. Remove backport pending label from this PR once all backport PRs are merged.

Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

backport pending Awaiting backport to stable release branch

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants

Comments