Postgres: TIMESTAMP WITHOUT TIME ZONE + java.sql.Timestamp stores JVM-local time; mixed-TZ fleets/DST corrupt ordering, lag, purge

Abierto
  • ¿Algo no está bien?
#135 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
35/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
kotlin, postgresql
Área
databases

Línea de trabajo

Start with PostgresOutboxStore, which binds created_at, updated_at and last_attempt with setTimestamp and reads them back with getTimestamp, and with the Postgres schema changesets that declare these columns as TIMESTAMP. Add a migration that converts the columns to timestamptz, then switch the store to OffsetDateTime binding and reading. Done when a test passes with a non-UTC TimeZone.setDefault and the migration path for existing users is documented.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

breaking-change bug

Severity: Medium · Area: okapi-postgres schema and JDBC mapping · Found in: code review of main @ e5630a1 (reasoned from pgjdbc semantics, not reproduced)

Problem

The Postgres schema declares created_at, updated_at and last_attempt as TIMESTAMP (without time zone). PostgresOutboxStore writes them with setTimestamp(Timestamp.from(instant)) and reads them with getTimestamp(...).toInstant(). pgjdbc renders a java.sql.Timestamp in the JVM default time zone, so the column stores local wall-clock time of whichever JVM wrote the row:

  • Mixed-TZ fleets (e.g. one pod with TZ=Europe/Warsaw, others UTC, or a developer laptop pointed at a shared DB):
    • ORDER BY created_at is skewed by hours
    • the lag gauge (okapi.entries.lag.seconds) is off by hours, possibly negative
    • the purger's last_attempt < cutoff deletes DELIVERED rows hours early or keeps them hours late
  • DST fall-back in a non-UTC zone: an hour of local times repeats, so two different instants map to the same stored value. Ordering and lag are wrong for that hour, and reading back can shift values by 1 h.

MySQL TIMESTAMP(6) normalizes to UTC, so this mainly affects Postgres.

Suggested fix

Migrate the columns to TIMESTAMPTZ (changeset 002 with ALTER COLUMN ... TYPE timestamptz USING ... AT TIME ZONE '<zone that wrote the data>', documented for existing users). Bind with setObject(i, instant.atOffset(ZoneOffset.UTC)) and read with getObject(col, OffsetDateTime::class.java). Add a test that runs the store with a non-UTC TimeZone.setDefault.

Lenguaje dominante
Kotlin
Estrellas
14
Forks
0
Merge medio
9 h 54 min
PR fusionados (30 d)
11

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de softwaremill/okapi

Todos los issues de softwaremill/okapi

Issues similares

Más issues de Kotlin

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.