Adding user - Error 409 Subscription request already pending
We have a couple of people trying to subscribe to our list but receive an error similar to: {"title": "409 Conflict", "description": "Subscription request already pending"}
If I try to Mass Subscribe them in Postorius I get this error: HTTP Error 409: b'{"title": "409 Conflict", "description": "Subscription request already pending"}'
In Postorius I don't see them hung up in Subscription requests.
What to do?
Thanks, Kevin
On 4/19/19 6:33 PM, kevin@coastalaska.org wrote:
We have a couple of people trying to subscribe to our list but receive an error similar to: {"title": "409 Conflict", "description": "Subscription request already pending"}
If I try to Mass Subscribe them in Postorius I get this error: HTTP Error 409: b'{"title": "409 Conflict", "description": "Subscription request already pending"}'
In Postorius I don't see them hung up in Subscription requests.
Postorius since 1.2.3 does not show subscription requests waiting user confirmation, only those waiting moderator approval.
Thus, if the list's subscription policy is confirm or confirm then moderate, the subscribing user will be sent an email requesting confirmation. If the user hasn't answered that email, the request is pending user confirmation, and since 1.2.3, you won't see it in Postorius. [Update: this is fixed in 1.2.4]
What to do?
have the user find the confirmation request email and confirm, or
wait for the request to expire (default 3 days)
using mailman shell or the REST api or direct interaction with the database, find the token and confirm it. A shell example is
mailman shell -l your.list.id
Welcome to the GNU Mailman shell
The variable 'm' is the your.list.id mailing list
>>> util = getUtility(IPendings)
>>> list(util.find(mlist=m,pend_type='subscription'))
This returns a list of items like ('hex_token'), {'token_owner': 'subscriber', 'email': 'user@example.com', 'display_name': 'Jane User', 'when': '2019-04-09T01:26:08', 'type': 'subscription', 'list_id': 'your.list.id'})
You then do
>>> util.confirm('hex_token')
Note that https://gitlab.com/mailman/postorius/issues/314 which was responsible for removing the subs waiting user confirmation from the Postorius listing suggested "there could be a different place to see the ones pending user approval, so that a moderator can look and/or delete those.", but that hasn't been done. [Update: this is fixed in 1.2.4]
-- Mark Sapiro mark@msapiro.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Thanks Mark,
This is sounding like a case of users will be users.
As you suggested, I think my moderator is dealing with a user that can't find their confirmation (or understand they need to reply to it). So the moderator tried to override things by trying to add them in by using the "mass subscribe" operation.
It sounded on Github that some opinion was that it wasn't necessary to see these pending requests, but as "users will be users" I think would be useful to see what is in queue for subscription requests, it would be better yet to be able to either clear them out or accept them there. But at very least seeing them there would go a long way helping out my moderators troubleshoot.
On another request, user found the confirmation email, replied, and was accepted. However that email was several weeks old. So I'm guessing our default for expiration of requests is not the default of 3 days. But I haven't been able to find that setting. Is that in Postorius somewhere or will I need to change with the shell?
I wonder if temporarily changing the Subscription Policy to "open" would allow those in pending to be accepted and clear that queue out?
Thanks again for the input, much appreciated!
Kevin Hurtley
CoastAlaska, Juneau, Alaska
Hi Kevin,
I have been following this thread. You won't be able to use the mailman shell due to this being a shared mailman 3 server. Just let me know what the email address is of the user that has an outstanding pending request and I should be able to clear that out via Mark's instructions. You can do that via our support ticket system.
I also wasn't aware of a setting for expiring pending requests. I will wait for Mark's response to look into that further. I can tell you from experiencing that making your subscription policy open will not allow those with pending requests to be added. I just tried that myself.
Brian
On 4/20/19 9:10 AM, brian@emwd.com wrote:
I also wasn't aware of a setting for expiring pending requests. I will wait for Mark's response to look into that further.
The setting is pending_request_life in the mailman section of mailman.cfg. The default is
pending_request_life: 3d
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Hi Mark,
I followed your instructions to confirm the user. When I ran ">> util.confirm('hex_token')" nothing happened which I take it to mean it worked. I then ran ">> list(util.find(mlist=m,pend_type='subscription'))" and the pending member did not show up which I thought was a good thing. But . . .
I tried to mass subscribe the user and got back:
"HTTP Error 409: b'{"title": "409 Conflict", "description": "Subscription request already pending"}'"
Brian
Nevermind, I restarted Mailman core and was able to successfully subscribe the user.
Brian
On 4/20/19 10:15 AM, brian@emwd.com wrote:
Nevermind, I restarted Mailman core and was able to successfully subscribe the user.
OK. Thanks for letting us know.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 4/20/19 10:13 AM, brian@emwd.com wrote:
Hi Mark,
I followed your instructions to confirm the user. When I ran ">> util.confirm('hex_token')" nothing happened which I take it to mean it worked. I then ran ">> list(util.find(mlist=m,pend_type='subscription'))" and the pending member did not show up which I thought was a good thing. But . . .
I tried to mass subscribe the user and got back:
"HTTP Error 409: b'{"title": "409 Conflict", "description": "Subscription request already pending"}'"
Did you do commit() or exit shell (which does an implicit commit) before trying the mass subscribe?
I'm not going to be able to look at this further for some time as I am traveling today, but I will.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 4/20/19 8:55 AM, Kevin Hurtley wrote:
It sounded on Github that some opinion was that it wasn't necessary to see these pending requests, but as "users will be users" I think would be useful to see what is in queue for subscription requests, it would be better yet to be able to either clear them out or accept them there. But at very least seeing them there would go a long way helping out my moderators troubleshoot.
The issue with the way Postorius displayed all the subscription requests was that it wasn't possible for the moderator to distinguish request waiting moderator approval from those waiting user confirmation, and in general a moderator shouldn't approve a request waiting user confirmation, but this thread shows there is sometimes a need for a moderator to be able to deal with these. I have reopened <https://gitlab.com/mailman/postorius/issues/314>, and will look at fixing this.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Which database table contains these pending subscriptions? I checked the "members" and "address" tables but no luck yet.
I'm trying to help someone clear a few hundred of these. I can try writing a Python script to use the "hex_token" values in the Python dict. But maybe doing something via MySQL would be easier.
On 6/16/22 15:46, Dan Caballero wrote:
Which database table contains these pending subscriptions? I checked the "members" and "address" tables but no luck yet.
I'm trying to help someone clear a few hundred of these. I can try writing a Python script to use the "hex_token" values in the Python dict. But maybe doing something via MySQL would be easier.
The tables are pended, pendedkeyvalue and workflowstate, but don't
do it via MySQL.
A mailman shell interaction like this is better.
$ ./mailman shell -l list.example.com
Welcome to the GNU Mailman shell
Use commit() to commit changes.
Use abort() to discard changes since the last commit.
Exit with ctrl+D does an implicit commit() but exit() does not.
The variable 'm' is the list.example.com mailing list
>>> util = getUtility(IPendings)
>>> for token, data in util.find(mlist=m, pend_type='subscription'):
... if data.token_owner == 'subscriber':
... util.confirm(token, expunge=True)
...
>>> commit()
>>>
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 6/16/22 16:32, Mark Sapiro wrote:
A
mailman shellinteraction like this is better.$ ./mailman shell -l list.example.com Welcome to the GNU Mailman shell Use commit() to commit changes. Use abort() to discard changes since the last commit. Exit with ctrl+D does an implicit commit() but exit() does not. The variable 'm' is the list.example.com mailing list >>> util = getUtility(IPendings) >>> for token, data in util.find(mlist=m, pend_type='subscription'): ... if data.token_owner == 'subscriber': ... util.confirm(token, expunge=True) ... >>> commit() >>>
There's an error in the above. The line
if data.token_owner == 'subscriber':
should be
if data['token_owner'] == 'subscriber':
Sorry for any confusion.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Thanks very much for the guidance. I ran the code and received the output for the list but after a commit and exit the members still weren't subscribed. I then ran mailman syncmembers using a list I had. That was able to complete this time and make all the necessary additions.
I'm going to see about making a wrapper script for future use. Thank you again.
On 6/17/22 12:19, Dan Caballero wrote:
Thanks very much for the guidance. I ran the code and received the output for the list but after a commit and exit the members still weren't subscribed.
That's expected. The process I posted only removes the pending request so a subsequent subscribe can succeed.
I then ran mailman syncmembers using a list I had. That was able to complete this time and make all the necessary additions.
I'm going to see about making a wrapper script for future use. Thank you again.
For Mailman core >=3.3.5 this should not be an issue. The underlying issue is https://gitlab.com/mailman/mailman/-/issues/729 which is fixed in 3.3.5. Now pending subscription confirmations expire after the configured pending_request_life (default 3 days) so they shouldn't hang around virtually for ever.
I just added some sample scripts to https://www.msapiro.net/scripts/. The script at https://www.msapiro.net/scripts/delete_orphans_expireds.py will delete subscriptions pending user confirmation that are older than the current pending_request_life.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Thanks again. Is it at all possible to run the delete_orphans_expired.py script on a specific list?
I've tried the listspec option with both mailman shell and mailman withlist commands but I get the error below.
TypeError: delete_orphans_expireds() takes 0 positional arguments but 1 was given
-- Dan
On 7/13/22 2:53 PM, Dan Caballero wrote:
Thanks again. Is it at all possible to run the delete_orphans_expired.py script on a specific list?
Not without significant modification to the script. However, since all it does is remove pending subscriptions waiting user confirmation that should have expired, but were pended prior to Mailman 3.3.5 with a 10 year lifetime, it shouldn't be harmful.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
participants (5)
-
brian＠emwd.com -
Dan Caballero -
Kevin Hurtley -
kevin＠coastalaska.org
-
Mark Sapiro