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

Fechada
  • Algo errado?
#135 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Um pull request relacionado já foi integrado.

  • #145 de @rawo — integrado

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
35/100
Tipo de issue
Bug
Clareza
Claramente especificada
Status de atividade
Ativa
Stack de tecnologia
kotlin, postgresql
Domínio
databases

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.

Linguagem predominante
Kotlin
Estrelas
14
Forks
0
Merge médio
14h 16min
PRs com merge (30d)
9

Preparar o ambiente

Este projeto não oferece contêiner de desenvolvimento, Dockerfile nem guia de contribuição, então a configuração fica por sua conta: comece pelo README e veja nosso guia da primeira contribuição para os passos gerais.

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de softwaremill/okapi

Todas as issues de softwaremill/okapi

Issues semelhantes

Mais issues de Kotlin

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.