We're updating the issue view to help you get more done.Learn more

Collections: Works occasionally not marked unrevealed and anonymous upon posting directly to an unrevealed or anonymous collection

Overview and steps to reproduce

If you have an anonymous, unrevealed collection (or, quite likely, a collection that is only one of those) and someone posts a work to said collection, the work and its creator may still be visible to all who encounter said work.

These steps will not always reproduce the bug, but here is the process:

  1. Log in

  2. Browse > Collections > New Collection

  3. Fill in required information

  4. Check both “This collection is unrevealed” and “This collection is anonymous”

  5. Press “Submit”

  6. Follow the “Post to Collection” link

  7. Fill in required information (the collection info will already be filled in because you used the “Post to Collection” link)

  8. Post Without Preview

Details

This is a fascinating situation where the Work is incorrect (in_anon_collection: false, in_unrevealed_collection: false), but the CollectionItem is correct (anonymous: true, unrevealed: true):

1 2 3 4 5 2.3.0 :001 > w = Work.find(000) => #<Work id: 000, expected_number_of_chapters: 1, created_at: "2017-11-17 20:20:18", updated_at: "2017-11-17 20:40:41", major_version: 1, minor_version: 1, posted: true, language_id: 1, restricted: false, word_count: 7498, hidden_by_admin: false, delta: false, revised_at: "2017-11-17 20:20:58", backdate: false, endnotes: "", imported_from_url: nil, hit_count_old: 0, last_visitor_old: nil, complete: true, summary_sanitizer_version: 1, notes_sanitizer_version: 1, endnotes_sanitizer_version: 1, work_skin_id: nil, in_anon_collection: false, in_unrevealed_collection: false, anon_commenting_disabled: false, spam: false, spam_checked_at: "2017-11-17 20:40:41", moderated_commenting_enabled: false> 2.3.0 :002 > c_i = CollectionItem.where(item_type: "Work", item_id: 000) => #<ActiveRecord::Relation [#<CollectionItem id: 000, collection_id: 105699, item_id: 000, item_type: "Work", user_approval_status: 1, collection_approval_status: 0, created_at: "2017-11-17 20:20:28", updated_at: "2017-11-17 20:20:28", anonymous: true, unrevealed: true>]>

Please note that the Work and CollectionItem IDs have been changed to 000 and some work fields (title, summary, notes, authors_to_sort_on, title_to_sort_on, ip_address) removed for privacy, as they are not relevant.

We confirmed that this work -- and at least one other work affected by this issue -- belonged only to one anonymous, unrevealed collection.

We note that the Work and CollectionItem were created at the exact same time (created_at: "2017-11-17 20:20:28"), although this is not in itself unusual -- it happens on works that are properly marked unrevealed and anonymous as well.

We suspect a race condition. 😭

CollectionItem.update_work is one of the few after_commit callbacks we have that tries to read data that was just written in the previous commit. Because it's an after_commit callback, not an after_save, the database queries to look up user_approved_collection_items (in update_anon_unrevealed, which is called by CollectionItem.update_work) occur outside of the transaction, which in theory would allow them them be routed to the read-only SQL servers, which have some chance of lagging behind the master SQL server by a transaction or two. (h/t ticking instant for the discovery and explanation.)

Testing

Because this cannot be reproduced at will, it is unlikely the fix can be tested. All we can do is take several shots at posting to an unrevealed, anonymous collection to confirm the correct behavior still happens and watch for any new reports of this bug after the fix is deployed.

Status

Assignee

ticking instant

Reporter

Sarken

Roadmap

Collections

Priority

Medium

Affects versions

0.9.221

Fix versions

Components

BackEnd

Difficulty

Hard

Milestone

Internal 0.9