slowdown since 7.14.0

in https://github.com/elastic/elasticsearch-py/pull/1623 a preflight request was added to / this has close to doubled response times for our aws lambda workflows is there any official guidance on how to address this regression when it comes to short lived environments? or is the only course of action to monkeypatch the validation and turn it off?

[lijok]

There won’t be a flag added to disable the product check for 7.x. In 8.x the product check will not use a pre-flight request.

What’s the rationale behind not adding a flag for disabling the product check? If the intention behind the change in the linked PR is to reduce number of issues raised to the repo due to someone using the library with an incompatible product, then that stance doesn’t make much sense to me. A flag would indicate the user understands what they’re doing and understands that the system they’re using this library with may be incompatible. As it stands right now, v7.14.0 kills the performance of our service running on aws lambda Our responses from lambdas that arent in the same region as the cluster have gone from taking 1.4s on average to 2.2s, which doesn’t fly under the radar

@sethmlarson are you ignoring my question? Because you closed the PR posted by @OriHoch , but have not replied here explaining the decision to not have a flag for disabling the product check

@kimchy I, as well as the rest of your customer base, would appreciate having changes like this thoroughly communicated and the rationale behind them explained. Having a product check in place, makes sense, to ensure that this repo issue tracker does not get bombarded with issues from users running the library against incompatible api’s. However, refusing a change that introduces a flag to disable this check, for users who are heavily impacted by the additional pre-flight request, makes this change look less like the team protecting themselves against bogus issues, and more like a kneejerk reaction to what aws is doing in respect to their fork. I will repeat myself. as it stands, v7.14.0 kills the performance of our service running on aws lambda, forcing us to version lock ourselves to v7.13.3 A massively impactful change like this being implemented, without adequate communication from leadership or project managers, is frankly unacceptable. All we’re left with is one maintainer with a hair trigger closing issues as soon as they’re opened, and not explaining himself whatsoever. I would highly prefer to avoid taking this through official channels, and I would prefer not to have to go through the hassle of migrating away from your hosted solution

So, I ask again: please explain the rationale behind not implementing a flag for disabling the product check?

[sethmlarson]

There isn’t a way to disable the product check aside from the route you mentioned. The info API is very quick to respond as no computation is done aside from sending version information so shouldn’t impact request latencies beyond a single RTT.