Skip to content
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

Release/3.2.1 #430

Draft
wants to merge 9 commits into
base: master
Choose a base branch
from
Draft

Release/3.2.1 #430

wants to merge 9 commits into from

Conversation

peel
Copy link
Contributor

@peel peel commented Sep 13, 2024

No description provided.

peel and others added 9 commits April 10, 2024 09:22
Previously `Content-Type` was not explicitly returned for POST requests.
This would result in errors being logged for javascript tracker in Firefox[1].
Now, the behavior is rolled back to previous where collector would return
`Content-Type` header for these requests.

Addresses [BCPF-1102] and [PDP-1110]

---

1 - https://bugzilla.mozilla.org/show_bug.cgi?id=884693
The goal of the feature was to prevent long body reads in GCP, this however does
not prevent the slow incoming connection handling at the framework level.
Therefore, as this adds unnecessary complexity with possible negative
performance impact, the feature is removed.

The configuration parameter is no longer used, but can remain as is.
Currently, healthchecks reside behind the same timeout settings as any other
endpoint. We observed that when autoscaling under massive load, it is possible
for collector to be taken down because of long health check responses.
Which previously did not happen. We therefore move healthchecks above the
timeout middleware to return to previous behavior.
Additionally, this allows us to set arbitrarily short (or long) response times
for the regular endpoints when necessary.

---

Part of [PDP-1408].
The reference defaults should be less strict and match the settings we define
upstream.
Previously, we would return 503 Service Unavailable, suggesting that failures
should not be retried and leading to confusion with early timeout being hit.
Now, we return 408 Request Timeout which is more explicit and easier to monitor.
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.

3 participants