A store that says its connection is finished is retried anyway, for ever #243

New issue

Closed

opened 2026-09-16 09:08:54 +00:00 by tiagoagueda · 0 comments

tiagoagueda commented

2026-09-16 09:08:54 +00:00

Owner

#216 gave plugins a way to say that the other side has done with a connection —
postulo.plugins.api.ConnectionUnusable — and notifiers honour it:
notifications/service.py:36 catches it, switches the connection off, shows the reason and
forgets the credential that is known not to work. A browser that has withdrawn its
subscription therefore stops being pushed to.

Stores do not. documents/archiving.py:127 catches bare Exception, so a store raising
ConnectionUnusable records an ordinary failed attempt whose message happens to begin
ConnectionUnusable:, and the copy is retried on the usual growing wait. Nothing switches
the connection off and nothing tells the person, so a Paperless instance that has revoked
its token, or a WebDAV share that no longer exists, goes on being dialled — once per
document, for every document, until somebody notices the failed badges.

This is why postulo-paperless#2 stopped short of raising it: raising it today changes
nothing except the words in the sentence a person reads, so the plugin would have been
promising something the core does not keep.

Proposal

send_copy catches ConnectionUnusable before the bare Exception, and does for a store
what the notifier does: connection.retire(reason), the copy marked failed with the
plugin's own sentence rather than a class name, and no further attempts.
Pending copies for a retired connection are not picked up by the scheduler's next pass —
decide whether they go to declined or stay waiting until the connection is allowed
again, and say which on the document.
The same question for sync plugins (plugins/models.py, the sync pass): a calendar that
answers 401 for ever is the same shape of problem.
A test that a store raising ConnectionUnusable retires the connection and stops, beside
the notifier test that already exists.

Found while fixing postulo-paperless#2, 2026-09-16.

#216 gave plugins a way to say that the other side has done with a connection — `postulo.plugins.api.ConnectionUnusable` — and notifiers honour it: `notifications/service.py:36` catches it, switches the connection off, shows the reason and forgets the credential that is known not to work. A browser that has withdrawn its subscription therefore stops being pushed to. Stores do not. `documents/archiving.py:127` catches bare `Exception`, so a store raising `ConnectionUnusable` records an ordinary failed attempt whose message happens to begin `ConnectionUnusable:`, and the copy is retried on the usual growing wait. Nothing switches the connection off and nothing tells the person, so a Paperless instance that has revoked its token, or a WebDAV share that no longer exists, goes on being dialled — once per document, for every document, until somebody notices the *failed* badges. This is why postulo-paperless#2 stopped short of raising it: raising it today changes nothing except the words in the sentence a person reads, so the plugin would have been promising something the core does not keep. ## Proposal - `send_copy` catches `ConnectionUnusable` before the bare `Exception`, and does for a store what the notifier does: `connection.retire(reason)`, the copy marked failed with the plugin's own sentence rather than a class name, and no further attempts. - Pending copies for a retired connection are not picked up by the scheduler's next pass — decide whether they go to *declined* or stay *waiting* until the connection is allowed again, and say which on the document. - The same question for sync plugins (`plugins/models.py`, the sync pass): a calendar that answers 401 for ever is the same shape of problem. - A test that a store raising `ConnectionUnusable` retires the connection and stops, beside the notifier test that already exists. Found while fixing postulo-paperless#2, 2026-09-16.

tiagoagueda added this to the 0.4.0 milestone

2026-09-16 09:08:54 +00:00

tiagoagueda added the

bug

label

2026-09-16 09:09:02 +00:00

tiagoagueda referenced this issue from a commit

2026-09-16 09:25:45 +00:00

Believe a store that says its connection is finished

tiagoagueda closed this issue

2026-09-16 09:25:45 +00:00