Remove unused LIST_PAGINATION_ENABLED feature configuration #2296
Conversation
|
Why is this unused? |
I have no idea. It was introduced in #1528, that's all I know. |
|
I think that this should have been used in #1938; does pagination now ignore this flag? |
github-project-automation
bot
moved this from PRs In Progress
to Ready to merge
in Basic Kanban Board
|
Adding if/else on the paginated call paths looks a bit of an overkill to me. As currently implemented, IIRC, pagination is controlled by the client. If the client does not request a call to be paginated, the server will work as before #1938. IMHO, the risk of breaking clients with current pagination code is low. |
|
We have feature flags for tons of things controlled by the client -- like table location overlap, generic tables, drop-with-purge, policies, etc. This flag was put in place specifically to guard against regressions caused by the new code path introduced by pagination. |
|
Fair point. I'll look into that presently. |
No description provided.