Exclusion robot could not be guessed for user

[bertaviader]

We are migrating our sympa to another server and with a new version. I'm doing the upgrade of the database to the new version and this error appears:

err main::#744 > Sympa::Upgrade::upgrade#883 Exclusion robot could not be guessed for user "X" in list "Y". Either this user is no longer subscribed to the list or the list appears in more than one robot (or the query to the database failed). Here is the list of robots in which this list name appears: ""

In this case we have two scenarios, either the user is subscribed and the error still appears or the user is subscribed and in the same time in the exclusion table of the interface.

Version

The previous version is Sympa 6.1.7
The new version is Sympa 6.2.24

Installation method

apt-get

Expected behavior

The user is not subscribed and inside the table of exclusion of the interface.

Actual behavior

The user is subscribed and the error still appears when I do the upgrade or the user is subscribed and in the same time inside the exclusion table of the interface.

[ikedas]

Hi @bertaviader,
If you can use SQL client utility (e.g. psql for PostgreSQL), can you run this query and show us the result?

SELECT robot_exclusion, family_exclusion FROM exclusion_table WHERE list_exclusion = 'Y' AND user_exclusion = 'X';

(Note: the result can be more than one row.)

[bertaviader]

Hi,
The result of the query is:

+-----------------+------------------+
| robot_exclusion | family_exclusion |
+-----------------+------------------+
|                 |                  |
+-----------------+------------------+

I guess this is not a normal result, can you guide me to the proper solution?
Thank you!

[ikedas]

It's normal result. The next, what is the result of this query?

SELECT COUNT(*) FROM subscriber_table WHERE list_subscriber = 'Y' AND user_subscriber = 'X';

If the user was really subscribing, the result would be a row containing 1 or more.

[bertaviader]

The result is this one:

+----------+
| COUNT(*) |
+----------+
|        0 |
+----------+

But in the web portal I can see the user subscribed to the list

[dverdin]

Hi @bertaviader !
Just to avoid the obvious: you did replace 'Y' by an actual list name and ''X' by a user address in @ikedas queries, didn't you?
Because you can't see subscribed people in the web interface if they are not in the database.
Other possibility: Sympa is querying your former database. Check the "db_*" parameters in your sympa.conf

[bertaviader]

Sorry! It was a mistake with the domain in the case above.
But this problem persist: the user is subscribed and in the same time in the exclusion table of the interface.
In this case the first query return this

+-----------------+------------------+
| robot_exclusion | family_exclusion |
+-----------------+------------------+
| llistes.upc.edu |                  |
+-----------------+------------------+

And the second query:

+----------+
| COUNT(*) |
+----------+
|        1 |
+----------+

Thank you!

[ikedas]

@bertaviader, thanks for confirming.
However, current behavior of upgrade is a bit irrational. I'll submit a pr to fix it.

But this problem persist: the user is subscribed and in the same time in the exclusion table of the interface.

I think it's not problem. Currently, once a user is added to exclusion table, they will be removed only if they are explicitly removed.

[bertaviader]

So If a message it's sent to the list, these subscribers that are in the exclusion table also, will receive the message?
Thank you,

[ikedas]

I got it. Don't worry. Content of exclusion_table affects inclusion of subscribers from data sources, not message delivery. Either a subscriber is included in it or not, messages will be delivered as the same.

[bertaviader]

With the fix you proportion I did again the upgrade and now the problem is solved.
Thank you so much!

[ikedas]

@bertaviader, thanks for confirming the pr. It will be included in the next stable release (maybe 6.2.42 in spring).

If you don’t have the other problems related to this issue, please close it. Thanks for reporting!