Error: entero fuera de rango

Esto funcionó para las post_actions, ¡gracias por la sugerencia!

Principalmente, todavía vemos dos fallos:

  1. GET https://devforum.roblox.com/notifications está devolviendo 404 para usuarios que tienen notificaciones con IDs bigInt.

  2. El trabajo programado Jobs::GrantAnniversaryBadges falla.

¿Es posible que un modelo/controlador/servicio de notificaciones todavía esté codificado para definir el campo notifications.id como un entero?

muy poco probable… 404 no suena bien, ¿hay algo en /logs que describa el problema?

Lamentablemente, no encuentro nada particularmente útil en /logs, pero cuando lo reproduzco localmente, veo que la solicitud llega y luego da 404, pero solo sucede cuando configuro mi última notificación con un ID que es un bigint (funciona bien cuando está dentro del rango de int32).

Investigando un poco, noto que obtengo una respuesta válida cuando llamo a 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"
}

Sin embargo, una vez que paso el parámetro de consulta recent, es decir, http://localhost/notifications.json?recent=true&limit=30, ¿y esto es lo que llama mi menú de notificaciones?

{
  "errors": [
    "La URL o el recurso solicitado no se pudo encontrar."
  ],
  "error_type": "not_found"
}

edición: estamos pensando que es porque current_user.seen_notification_id sigue siendo un entero :thinking:

¡Creo que ya estamos fuera de peligro!

Nos dimos cuenta de que necesitábamos migrar columnas en otras tablas que hacían referencia a notification_id además de notifications.id en sí. De lo contrario, services/notifications.rb o services/badge_granter.rb lanzarían errores.


Para cualquier otra configuración de foro grande que se encuentre con esto en el futuro con las notificaciones, esto es lo que hicimos…

En total, tuvimos que migrar cuatro columnas en cuatro tablas:

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

Inicialmente, abordamos el punto 1 con el comando ALTER sugerido anteriormente, pero luego, como se mencionó, optamos por usar migraciones de ActiveRecord, de esa manera los archivos de migración se suman al esquema.

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

Tenemos un Dockerfile personalizado en nuestra configuración (construimos imágenes para poder ejecutar discourse y sidekiq en recursos separados en Kubernetes), por lo que copiar estos archivos a /db/migrate como parte de nuestro Dockerfile fue sencillo.

Luego, simplemente dejamos que rake db:migrate se encargara del resto. Una vez que hicimos un reinicio escalonado de todos nuestros pods de discourse y sidekiq, todo funcionaba como se esperaba :crossed_fingers:.

3 Me gusta

Excelentes datos, vamos a aceptar la migración en el núcleo de Discourse a un bigint. Es un movimiento costoso, pero esto ciertamente volverá a surgir en foros grandes, así que más vale que lo arreglemos.

Nota… el OP trata sobre post_id… desbordar eso será mucho más difícil que las notificaciones. Ciertamente ocurrirán 2.1 mil millones de publicaciones, pero el costo de convertir post_id a bigint es mucho más costoso que el de notification id. Podemos esperar un poco con esa bomba de tiempo.

4 Me gusta

Brandon,

Creo que podríamos terminar optando por:

El equilibrio aquí es que no quiero “castigar” a 40k instancias de Discourse debido a uno o dos foros atípicos que lograron la asombrosa hazaña de 2.5 mil millones de notificaciones.

¿Qué opinas?

(Nota: También capturará al menos uno que te perdiste: también hay una tabla de chat)

3 Me gusta

Esto sería genial y parece una solución inteligente :slight_smile:

Para volver a este tema, esto ya se ha fusionado. :partying_face:

5 Me gusta

Este tema se cerró automáticamente después de 4 días. Ya no se permiten nuevas respuestas.