Several Rails developers have identified a bug in which Active Record collections using a limit or offset (i.e. used for paginating records) don't always return fresh cache key versions after their contents have changed. (See comments on pull request #20884 <https://github.com/rails/rails/pull/20884#issuecomment-128910649>, and issues #31996 <https://github.com/rails/rails/issues/31996>, #34408 <https://github.com/rails/rails/issues/34408> and #37555 <https://github.com/rails/rails/issues/37555>.)
This is due to the current mechanism for generating cache key versions (a collection's size concatenated with its maximum updated_at timestamp), which isn't quite robust/unique enough. I propose to mitigate this by including a collection's first and last IDs in its cache version, for collections using a limit or offset: https://github.com/rails/rails/pull/37724 (I submitted my pull request a couple weeks ago - I'm aware a lot of folks may be taking time off for the holidays, but am creating a new thread hoping to attract some reviewers/feedback. Any attention from the Rails team or others is greatly appreciated!) Anyway, there are a couple ways we might go about attacking this - in particular PR #21503 <https://github.com/rails/rails/pull/21503> proposes including a hash digest of IDs to ensure fresh cache versions. (Please see my pull request's summary for a more detailed analysis of alternative solutions.) Regardless of which way we go, I'm hoping we engineer a solution! -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-core/CAEJZ43gUfyriYMK1D%2Br1FoNAxk0Vyk84VmLzesq93RJfdFAqAA%40mail.gmail.com.
