Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Slug regenerated #1010

Open
jjf21 opened this issue Jun 5, 2023 · 0 comments
Open

Slug regenerated #1010

jjf21 opened this issue Jun 5, 2023 · 0 comments

Comments

@jjf21
Copy link

jjf21 commented Jun 5, 2023

Hi, we encounter a strange bug using the gem.

Some of our records have seen their slug generated 2 times, the first one correctly and the second one incorrectly.

>  FriendlyId::Slug.where(sluggable_type: "Contact", sluggable_id: contact.id)
=>
[#<FriendlyId::Slug:0x000055e8ed64a790
  id: 295947,
  slug: "tony-thee",
  sluggable_id: 17554,
  sluggable_type: "Contact",
  scope: nil,
  created_at: Sat, 06 May 2023 15:38:17.448619000 CEST +02:00>,
 #<FriendlyId::Slug:0x000055e8ed64a498
  id: 295948,
  slug: "36e81d8e-f5fd-4eaa-a3bd-4a77ab8db603",
  sluggable_id: 17554,
  sluggable_type: "Contact",
  scope: nil,
  created_at: Sat, 06 May 2023 15:38:17.655258000 CEST +02:00>]

We can see that the first one is created using the correct slug tony-thee and the second one is using a UUID, which is not the Contact#uuid.

the slug uses a full_name which is set in a before_validation callback

# models/contact.rb
friendly_id :full_name, use: :history
before_validation :set_full_name

We conclude that as the first slug created has always the good slug, so that it's not a problem with callbacks order.

This issue happened only on 60 records, out of 30k on production, but we can't find how to reproduce it local env.

I am looking for any know issues that could create this kind of behavior.
Thanks for you help !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant