Skip to content

Relax inffecient query validation for deployments api

Vladimir Shushlin requested to merge vshushlin/deployment-api-relax-validation into master

What does this MR do and why?

We were planning to deprecate usage of order=updated_at and updated_before/afted= without each other in the deployments API(you can still use them if you combine these 2 options). Mainly because users can create not very efficient queries like: updated_before=something&order=id, and we don't have index to facilitate this query.

While investigating [existing usage do deployments API]#328500 (comment 1360432298)), I realized that some users are using completely legit query order=updated_at&sort=desc which is basically "give me deployments sorted by the time they were updating".

If we just implemented [Breaking Change] Returns an error when `update... (#328500 - closed) as is, e.g. in Draft: Remove deployments_raise_updated_at_inef... (!116658 - closed), we would:

  1. affect a lot of users workflows
  2. force them add a workaround like "updated_after=1970..." which won't make the query more efficient.

So this MR relaxes the inefficient query validation: now if you use updated_before/after you need to also specify sorting, but you can use order=updated_at without these filters...

This should minimize impact on existing user workflows while still allowing us to deprecate unreasonable and performance affecting queries like updated_before=something&order=id.

Once this is in production, I'll reevaluate the impact, and adjust the Draft: Remove deployments_raise_updated_at_inef... (!116658 - closed)

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Merge request reports