In latest Dassie (Ruby 3.3, Rails 7.2), changing file order does not change order of files in IIIF manifest

[nhomenda]

Descriptive summary

In latest Dassie (Ruby 3.3, Rails 7.2), changing file order does not change order of files in IIIF manifest

Steps to reproduce the behavior in User Interface (UI)

In Dassie (https://dev.nurax.samvera.org/), create a work and attach multiple files
Save the work
Using the file manager, reorder the files and save.
Notice the order of files has changed in "Items":

The order of files in the IIIF manifest/UV remains unchanged: https://dev.nurax.samvera.org/concern/generic_works/6108vb65k/manifest

Acceptance Criteria/Expected Behavior

Changing file order changes order of files in IIIF manifest. This works in Koppie/ pg.nurax

[randalldfloyd]

Adding notes from extensive troubleshooting to help me keep track of details:

For a Wings work, ordering files seems really messed up:

Not only does the order of 'members; not stick, it looks like it is duplicating member and aggregation proxies (list_source) for every re-ordering attempt

Observation from creation of new Wings work in UI, re-ordering in File Manager:

On initial creation, everything in Fedora and Solr is correct. The order of members (member_ids) is the processed and stored order. Order of proxies in list_source is correct; Solr field is correctly ordered.
After attempting to re-order 2 filesets, there are now 10 proxies in members, and 5 entries in list source; only 2 are referenced but first/last is correct for order; order in Solr field is wrong, which must have come from members.

Other notes:

For a AF work, the original positions of proxies in the 'members' indirect container is never touched when ordering (only when adding/removing members)
For a AF work, re-ordering re-arranges the proxy-for containers in 'list_source' to reflect the logical order

Path of execution when Wings resource is walked through AF conversion and saved (bottom-up):

lib/wings/valkyrie/persister.rb:40
lib/wings/active_fedora_converter.rb:155
lib/wings/active_fedora_converter.rb:141
lib/wings/active_fedora_converter.rb:68
lib/wings/valkyrie/resource_factory.rb:30
lib/wings/valkyrie/persister.rb:29
lib/hyrax/transactions/steps/save.rb
lib/hyrax/transactions/transaction.rb
...
app/controllers/concerns/hyrax/works_controller_behavior.rb:216:in `update_valkyrie_work'
app/controllers/concerns/hyrax/works_controller_behavior.rb:104:in `update'

[randalldfloyd]

The most likely place that things go wrong is here, in the ActiveFedoraConverter :

if converted_attrs.keys.include?(:members)
    members = Array.wrap(converted_attrs.delete(:members))
    members.empty? ? af_object.try(:ordered_members)&.clear : af_object.try(:ordered_members=, members)
    af_object.try(:members)&.replace(members)
end

This block does seem to save the correct order to list_source, but it does not update the members container properly. It has exponential growth of members with every re-order/save, and its returned order never matches what is returned through ordered_member_ids, which is the list_source. But a Wings model only has one container for this, member_ids, and that is mapped to the AF members , which represents the unordered container, not list_source.

For comparison, look at the heavy lifting expected to be done in those couple lines with the AF equivalent code that handles re-ordering, which has its own actor in the Actor Stack.