When we've made the restrictions table we've made a critical mistake - the order of the rev clustering key was set to asc, so now for requests without the revision if there're multiple entities in the table, the earliest revision would be selected while we actually need the latest.

Unfortunately, we already have a lot of data in the table, and altering the table to change the clustering key order is not supported. This means we need to proceed with a lot of manual steps:

• Create a new restrictions table with the same schema and desc rev key order.
• Switch to it in production to start writing to it.
• Run a script to reload all the data from old restrictions table to the new one
• Drop the old restriction table.

Obviously, we cannot switch to the restriction-based access control before this is resolved.