Skip to content

add headers reporting uncompressed size and doc count #1217

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 8 commits into
base: main
Choose a base branch
from

Conversation

jsvd
Copy link
Member

@jsvd jsvd commented Jul 21, 2025

Adds two new headers to each bulk request:

  • "X-Elastic-Event-Count": number of actions / documents in that bulk request
  • "X-Elastic-Uncompressed-Request-Length": size in bytes of the request body before compression

X-Elastic-Uncompressed-Request-Length is equal to Content-Length when compression is disabled.

aligns with elastic/beats#45146

also renews test certificates that were out-of-date.

@jsvd jsvd requested a review from robbavey July 22, 2025 16:00
Copy link
Contributor

@robbavey robbavey left a comment

Choose a reason for hiding this comment

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

Code looks good to me - I added a comment on Travis test scopes, which can be resolved here, or in a separate PR

@@ -8,7 +8,6 @@ jobs:
- env: INTEGRATION=true SNAPSHOT=true LOG_LEVEL=info ELASTIC_STACK_VERSION=8.previous
- env: INTEGRATION=true SNAPSHOT=true LOG_LEVEL=info ELASTIC_STACK_VERSION=8.current
- env: INTEGRATION=true SNAPSHOT=true LOG_LEVEL=info ELASTIC_STACK_VERSION=8.next
- env: INTEGRATION=true SNAPSHOT=true LOG_LEVEL=info ELASTIC_STACK_VERSION=8.future
- env: INTEGRATION=true SNAPSHOT=true LOG_LEVEL=info ELASTIC_STACK_VERSION=main
- stage: "Secure Integration Tests"
env: SECURE_INTEGRATION=true INTEGRATION=true LOG_LEVEL=info ELASTIC_STACK_VERSION=8.current SNAPSHOT=true
Copy link
Contributor

Choose a reason for hiding this comment

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

This might be better done in a separate PR, but given this PR is targeted to main, does it make sense to have 9.previous, 9.current, etc, instead of 8.blah? Or at least, as well as?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants