bullet-train-co / bullet_train-core

Given the way we use cursor pagination and an after attribute with the ID of the last result, I would have expected IDs to be ascending order, but they're not. As a result of this, pagination is effectively broken, at least on MySQL?

I fixed this downstream by overriding apply_pagination like so. The important part here is the order: {id: :asc}.

  def apply_pagination
     collection = instance_variable_get collection_variable
     # The `pagy_cursor` gem appears to default to `order: {id: :desc}`?
     @pagy, collection = pagy_cursor collection, after: params[:after], order: {id: :asc}
     instance_variable_set collection_variable, collection
   end

Very strange... I noticed it happening recently on my machine, and I reverted back to 1.25.0 for all of our BT gems but I still get the same test failure there so I'm not sure where it was introduced 🤔 Using PostgreSQL.

I'm seeing that the following bit (that our pagination test uses) returns tangible things in descending order

bullet_train-core/bullet_train-super_scaffolding/app/views/account/scaffolding/absolutely_abstract/creative_concepts/show.html.erb

Line 50 in f55ccc4

    
               <%= render 'account/scaffolding/completely_concrete/tangible_things/index', tangible_things: @creative_concept.completely_concrete_tangible_things, hide_back: true %>

Tagging the oldest scope onto the end returns them in the proper order, but it seems like this is happening before we even hit pagy in the index partial. Will continue digging.

I went ahead and merged #409 so that we can get a fix in place, but I'm leaving this issue open so that we can look for a better fix to the root cause.

API controller indexes are ordered backwards.