Retrying Queued Messages Results in Jan 01 2000 +0 Timestamp

Issues
1

Issue Description

Retrying queued messages shows a timestamp of Jan 1 2000 +0 instead of time of action.

Expected Behavior

Next retry should be the current time.

Actual Behavior

Next retry shows 1999-12-31, 5:00:00 p.m. (my timezone is MDT -6)

Reproduction Steps

Wait until a message is in the queue and attempt to resend it.

Stalwart Version

v0.16.x

Installation Method

Binary (Linux)

Database Backend

PostgreSQL

Blob Storage

S3-compatible

Search Engine

Internal

Directory Backend

Internal

Additional Context

v0.16.24 but also occurred in previous versions.

I have reviewed the documentation and FAQ and confirm that my issue is NOT addressed there.

on

I have searched this support forum (open and closed topics) and confirm this is not a duplicate.

on

I understand that topics in this category are triaged by a bot first but a human reply will follow up. If I’d prefer a human-only reply, I’ll add the no-ai tag to my topic.

on

2

This isn’t covered in the current docs. A community member or staff member will follow up.

This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong.

3

I have the same problem and in addition to that NO email is ever being delivered (from outside to inside nor inside to outside)

No visible error message, nothing in the logs

Stalwart Version 0.16.24, e-mail were received by version 0.16.21

MySQL Data store

Blob Store S3-compatible

Install method Install-Script from GitHub

The system is a cluster of three nodes, all running the same version. Cluster stat is all nodes active

4

My messages do deliver, it is a display issue with time stamping only. I would open a separate issue with more details to receive better assistance.

5

“Retry Now” works by setting the next retry to 2000-01-01 00:00 UTC. A date in the past makes the message due immediately, and the queue picks it up straight away; what you’re looking at is that marker until the attempt runs. If delivery succeeds the message leaves the queue, and if it fails the marker is replaced by a real retry time. Showing the current time there would be less confusing, and I’d like to change that.

A message that stays at that date for more than a minute or so would be a real problem, and the queue log lines for its id would show why.

@mathias.gaertner, nothing being delivered at all on a three-node cluster is a separate issue. Please open your own topic with the queue and delivery events at debug level from the node that accepted the message.

6

Hi,

well I must have had a complete config mess. After deleting everything and setting up all cluster nodes anew I do have at least a running system…