Errore: intero fuori intervallo

Questo ha funzionato per post_actions, grazie per il suggerimento!

Ora vediamo ancora principalmente due errori:

  1. GET https://devforum.roblox.com/notifications restituisce 404 per gli utenti che hanno notifiche con ID bigInt.

  2. Il processo pianificato Jobs::GrantAnniversaryBadges fallisce.

È possibile che un modello/controller/servizio di notifiche sia ancora codificato in modo fisso per definire il campo notifications.id come un intero?

molto improbabile … 404 non sembra giusto, c’è qualcosa in /logs che descrive il problema?

Purtroppo non riesco a trovare nulla di particolarmente utile in /logs stesso, ma quando lo riproduco localmente vedo arrivare la richiesta e poi 404, ma succede solo quando imposto la mia ultima notifica con un id che è un bigint (funziona perfettamente quando è nell’intervallo int32)

Esaminando, noto che ricevo una risposta valida quando chiamo http://localhost/notifications.json?limit=30:

{
  "notifications": [
    {
      "id": 2148935910,
      "user_id": 2,
      "notification_type": 5,
      "read": true,
      "high_priority": false,
      "created_at": "2023-02-16T00:50:53.135Z",
      "post_number": 2,
      "topic_id": 8,
      "fancy_title": "Welcome to the Lounge",
      "slug": "welcome-to-the-lounge",
      "data": {
        "topic_title": "Welcome to the Lounge",
        "original_post_id": 13,
        "original_post_type": 1,
        "original_username": "blarouche",
        "revision_number": null,
        "display_username": "blarouche"
      }
    }
  ],
  "total_rows_notifications": 1,
  "seen_notification_id": 1001,
  "load_more_notifications": "/notifications?offset=60&username=bjlarouche"
}

Tuttavia, una volta che passo il parametro di query recent, cioè http://localhost/notifications.json?recent=true&limit=30, ed è questo che viene chiamato dal menu delle notifiche?

{
  "errors": [
    "The requested URL or resource could not be found."
  ],
  "error_type": "not_found"
}

edit: stiamo pensando che sia perché current_user.seen_notification_id è ancora un intero :thinking:

Penso che ora siamo fuori pericolo!

Abbiamo notato che era necessario migrare le colonne in altre tabelle che facevano riferimento a notification_id oltre a notifications.id stesso. Altrimenti, services/notifications.rb o services/badge_granter.rb avrebbero generato errori.


Per qualsiasi altro grande setup di forum che si imbatta in questo in futuro con le notifiche, ecco cosa abbiamo fatto…

In totale, abbiamo dovuto migrare quattro colonne in quattro tabelle:

  1. notifications.id
  2. user.seen_notification_id
  3. user_badges.notification_id
  4. shelved_notifications.notification_id

Inizialmente abbiamo proceduto con il comando ALTER suggerito sopra per il punto 1, ma poi, come menzionato, abbiamo optato per utilizzare le migrazioni ActiveRecord, in modo che i file di migrazione si aggiungano allo schema.

20230215070319_change_notifications_id_to_bigint.rb
# frozen_string_literal: true

class ChangeNotificationsIdToBigint < ActiveRecord::Migration[6.1]
    def change
        change_column :notifications, :id, :bigint
    end
end
20230215070320_change_user_seen_notification_id_to_bigint.rb
# frozen_string_literal: true

class ChangeUserSeenNotificationIdToBigint < ActiveRecord::Migration[6.1]
    def change
        change_column :users, :seen_notification_id, :bigint
    end
end
20230215070321_change_user_badges_notification_id_to_bigint.rb
# frozen_string_literal: true

class ChangeUserBadgesNotificationIdToBigint < ActiveRecord::Migration[6.1]
    def change
        change_column :user_badges, :notification_id, :bigint
    end
end
20230215070322_change_shelved_notifications_notification_id_to_bigint.rb
# frozen_string_literal: true

class ChangeShelvedNotificationsNotificationIdToBigint < ActiveRecord::Migration[6.1]
    def change
        change_column :shelved_notifications, :notification_id, :bigint
    end
end

Abbiamo un Dockerfile personalizzato nel nostro setup (costruiamo immagini in modo da poter eseguire discourse e sidekiq su risorse separate in Kubernetes), quindi copiare questi file in /db/migrate come parte del nostro Dockerfile è stato semplice.

Poi, abbiamo semplicemente lasciato che rake db:migrate facesse il resto. Una volta eseguito un riavvio graduale di tutti i nostri pod discourse e sidekiq, tutto funzionava come previsto :crossed_fingers:.

3 Mi Piace

Ottimi dati, decideremo di affrontare la migrazione in core discourse a un bigint. È una mossa costosa, ma sicuramente si ripresenterà su forum di grandi dimensioni, quindi tanto vale risolverla.

Nota… l’OP riguarda post_id… il superamento di tale limite sarà molto più difficile rispetto alle notifiche. 2,1 miliardi di post accadranno sicuramente, ma il costo del biginting di post_id è molto più costoso di quello di notification id. Possiamo aspettare un po’ per questa bomba a orologeria.

4 Mi Piace

Brandon,

Penso che potremmo finire per scegliere:

L’equilibrio qui è che non voglio “punire” 40k istanze di Discourse a causa di uno o due forum anomali che sono riusciti a raggiungere l’incredibile traguardo di 2,5 miliardi di notifiche.

Cosa ne pensi?

(Nota: catturerà anche almeno una che ti è sfuggita: c’è anche una tabella di chat)

3 Mi Piace

Sarebbe fantastico e sembra una soluzione intelligente :slight_smile:

Tornando a questo punto: ora è stato unito. :partying_face:

5 Mi Piace

Questo argomento è stato chiuso automaticamente dopo 4 giorni. Non sono più ammessi nuovi messaggi.