Guard against out-of-bounds sequence number from server. v1 PROPOSED

Brett Buddin
Brett Buddin: 1
 Guard against out-of-bounds sequence number from server.

 1 files changed, 3 insertions(+), 0 deletions(-)
Export patchset (mbox)
How do I use this?

Copy & paste the following snippet into your terminal to import this patchset into git:

curl -s https://lists.sr.ht/~sircmpwn/aerc/patches/7992/mbox | git am -3
Learn more about email & git

[PATCH] Guard against out-of-bounds sequence number from server. Export this patch

Brett Buddin
When archiving a large block of messages, Gmail frequently sends expunge
updates to the client with an out-of-bounds sequence number. This is an
attempt to deal with the situation by guarding access to the UUID
mapping with a bounds check.

I'm not sure if this is a long-term solution to the issue. There could
be an problem with the way the deletion/fetching operations interact
with each other or with the IMAP client. This appears to fix the problem
on my end though.

This addresses: https://todo.sr.ht/~sircmpwn/aerc2/239
 worker/imap/worker.go | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/worker/imap/worker.go b/worker/imap/worker.go
index cd63c39..760118c 100644
--- a/worker/imap/worker.go
+++ b/worker/imap/worker.go
@@ -226,6 +226,9 @@ func (w *IMAPWorker) handleImapUpdate(update client.Update) {
		}, nil)
	case *client.ExpungeUpdate:
		i := update.SeqNum - 1
		if i >= uint32(len(w.seqMap)) {
		uid := w.seqMap[i]
		w.seqMap = append(w.seqMap[:i], w.seqMap[i+1:]...)
I think the more likely explanation is a race condition where an id
becomes invalid before we've had a chance to process it.
View this thread in the archives