Files
kumomta/crates
Wez Furlong 2b1146aa91 queue: avoid potential "singleton_wheel: reinsert_ready: metadata must be loaded first"
There is a potential race between the timerwheel tick and bulk queue
operations (flushing, bouncing).  The logic in the tick case has
some accommodations for this, but there is another outstanding
that can result in racing to manage the metadata load state
on a message.

In the tick case, we load it if needed, then resolve the queue
name, so that we can resolve the Queue handle.

We need the queue handle to decide whether we are responsible
for the message, or whether we might be racing with a concurrent
action.

In the race case, the other actor may have decided to release
the message metadata, which will cause the queue name resolution
to fail.

While we could just shrug and silently ignore the error in that
case, that makes me uneasy.

What this commit does is adjust the v1 wheel entry so that we
capture weak references to both the message and its containing
queue.

Then when we tick, we can simply upgrade both of those and
reconcile without needing to manipulate any message metadata.

These changes unfortunately result in re-duplication of some
of the logic that I recently refactored to be shared with the
v2 tick implementation.

The v2 tick implementation has the same edge case around
metadata, but cannot be easily adjusted to use the same
pattern.

So this commit sticks a comment in the code; nobody is using
v2 AFAIK, and there have been reports of some wonky behavior
with it.  My recommendation at this time is to avoid using
the v2 wheel and we can fix this all up for it later.
2025-04-04 15:52:17 -07:00
..
2024-12-07 09:17:54 -07:00
2025-04-02 05:16:17 -07:00
2024-12-07 09:17:54 -07:00
2024-12-07 09:17:54 -07:00
2024-12-07 09:17:54 -07:00
2024-12-07 09:17:54 -07:00
2024-12-07 09:17:54 -07:00
2024-12-07 09:17:54 -07:00
2025-04-02 05:16:17 -07:00
2024-12-07 09:17:54 -07:00
2025-04-02 14:25:25 -07:00
2024-11-13 13:50:27 -07:00
2025-03-12 11:07:52 -07:00