Db:seed_fu fallisce su 002_groups.rb durante l'aggiornamento: Validazione fallita: Nome già presente

Contribuisci Bug
1

Ho riscontrato un problema durante l’aggiornamento da v2026.3.0-latest. Il task rake db:seed_fu fallisce quando raggiunge 002_groups.rb con questo errore:

ActiveRecord::RecordInvalid: Validation failed: Name has already been taken. (ActiveRecord::RecordInvalid)

Il crash avviene proprio quando il seeder tenta di inizializzare i nuovi gruppi di sistema (ID 4: anonymous e ID 5: logged_in_users).

Ho confermato la situazione tramite la console di Rails. Eseguire un controllo manuale fallisce per validazione, ma bypassando la validazione il database accetta il record senza alcun problema:

# Questo fallisce con «Name has already been taken»
g = Group.new(id: 4, name: "anonymous", automatic: true)
g.valid?

# Questo funziona correttamente, dimostrando che non c'è un vero conflitto
g.save(validate: false)

Sono riuscito a superare questo ostacolo creando manualmente questi nuovi gruppi di sistema:

ActiveRecord::Base.transaction do
  g4 = Group.new(id: 4, name: "anonymous", automatic: true)
  g4.save(validate: false)

  g5 = Group.new(id: 5, name: "logged_in_users", automatic: true)
  g5.save(validate: false)
end

Ora, quando eseguo rake db:seed_fu, il processo si completa senza errori.

2 Mi Piace
2

Dov’è finito il pulsante “Anche io!”?

Questo accade quando esiste già un gruppo o un utente (!!!) chiamato anonymous.

Abbiamo molti forum in cui anonymous è stato utilizzato come nome utente dopo un’importazione.
Il commit menziona

Questa PR introduce due nuovi gruppi automatici: anonymous_users e logged_in_users

ma a quanto pare il gruppo è stato infine chiamato anonymous senza _users.

È un peccato perché

  • anonymous rende poco chiaro se si tratta di un gruppo di utenti o di un singolo utente
  • il rischio di un conflitto con un gruppo o un utente esistente è molto più alto senza _users

Soluzioni suggerite:
1 - rinominare il gruppo in anonymous_users, in linea con logged_in_users e riducendo enormemente il rischio di conflitti
2 - almeno rilevare il conflitto e rinominare l’utente o il gruppo esistente invece di generare un errore

2 Mi Piace
5

Sto dando un’occhiata a questo.

Esiste una migrazione per gestire questo conflitto di nomi, quindi non sono sicuro del motivo per cui non funziona nel caso dell’OP:

Lo stai eseguendo da solo prima di eseguire le migrazioni?

6

La tua migrazione esamina i gruppi esistenti. Tuttavia, dovrebbe esaminare anche gli utenti esistenti, poiché utenti e gruppi condividono uno stesso namespace e non è possibile avere un gruppo con lo stesso nome di un utente.

7

Hmm, ok, è piuttosto fastidioso… sto creando una PR per farlo:

Il che, come dici tu, dovrebbe ridurre drasticamente la possibilità di un conflitto. Dubito molto che esista un utente chiamato anonymous_users, quindi non penso sia necessaria una verifica o migrazione automatica se eseguo questa rinomina.

1 Mi Piace
8

Ok, questo dovrebbe funzionare; risolve anche alcuni problemi con la logica di modifica imminente per https://meta.discourse.org/t/granular-group-based-permissions-for-anonymous-and-logged-in-users/402273:

https://github.com/discourse/discourse/pull/40435

2 Mi Piace
12

Inizialmente no. Falliva durante le migrazioni nel processo standard di rebuild, ed è così che è stato portato alla mia attenzione inizialmente e l’ho individuato. Stavo poi eseguendo manualmente il task rake per la risoluzione dei problemi.

2 Mi Piace
13

D’accordo, ho unito la PR ora, dovrebbe risolvere i conflitti di nome.

1 Mi Piace
14

Questa è un’ottima notizia!

Potresti anche applicare la correzione in backport alla versione 2026.5?