Regression in 5.2.5 - not adding GUID hashes to duplicate slugs

[jeffblake]

I have something like this

class Event
   friendly_id :slug_candidates, use: [:slugged, :history, :finders]
    
  def slug_candidates
   [:name, [:name, :event_times]]
  end
end

Where event_times basically calls strftime on a date field, e.g. 4:00pm-5:00pm

So if I call dup with 5.2.5 on an existing record, and try to save the new one, it causes a unique index violation, but does not do that on 5.2.4

[jeffblake]

Bump?

[parndt]

Hmm thanks @jeffblake -- have you managed to track it down to a particular commit? I'm guessing it'll be the same in 5.3.0

[jeffblake]

This perhaps? fd2d379

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[jeffblake]

Hi, thought I'd follow up on this.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[parndt]

I think this still needs fixing

[tfwright]

I just ran into this in 5.2.4 when using the history module. Updating a slug for an existing user was causing a slug collision. The reason was that some existing slugs didn't have corresponding history records. Creating those missing history records manually in console solved the issue. This seems like a bug because my expectation was that history was only a fallback for finding records, not a source of truth for creating slugs.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[parndt]

I think I'm going to need help with this, please

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[trappist]

@jeffblake I may have just encountered this, and it seems to be caused by a soft-deleted (paranoid) record causing the collision.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.