Problems with mod_pubsub

[di72nn]

Hey!

I'm running a personal server (so problems may be detected and addressed quite late) and I've been having weird issues with mod_pubsub.
First, there was this issue (but disabling last_item_cache seems to have solved it at the time).

Now I notice these errors in the log:

[error] <0.577.0>@mod_pubsub:get_transaction_response/1:3915 Transaction aborted:
** exception error: no case clause matching {odbc,true}
   in function  pubsub_node_config:'-encode/3-lc$^0/1-0-'/3 (src/pubsub_node_config.erl, line 222)
   in call from pubsub_node_config:'-encode/3-lc$^0/1-0-'/3 (src/pubsub_node_config.erl, line 423)
   in call from pubsub_node_config:encode/3 (src/pubsub_node_config.erl, line 423)
   in call from mod_pubsub:'-get_configure/5-fun-0-'/6 (src/mod_pubsub.erl, line 3302)
   in call from mod_pubsub:'-transaction/4-fun-0-'/3 (src/mod_pubsub.erl, line 3854)
   in call from mod_pubsub:'-do_transaction/4-fun-0-'/3 (src/mod_pubsub.erl, line 3876)
   in call from ejabberd_sql:execute_bloc/1 (src/ejabberd_sql.erl, line 571)
   in call from ejabberd_sql:run_sql_cmd/4 (src/ejabberd_sql.erl, line 488)

These appear when I connect with gajim (and presumably it tries to update OMEMO-related pubsub stuff, because other devices seems to quickly "forget" about this client when it leaves).

I'm running ejabberd 21.07, but I can see the errors in the log since at least 21.01 (with slightly different line numbers in different ejabberd versions).

Relevant config parts:

default_db: sql
sql_type: mysql
...

modules:
  mod_pubsub:
    access_createnode: pubsub_createnode
    ignore_pep_from_offline: false
    last_item_cache: false
    plugins:
      - flat
      - pep
    force_node_config:
      storage:bookmarks:
        access_model: whitelist

I'm hoping the stacktrace will be enough to start figuring this out.

[badlop]

I was not able to reproduce that crash, but looking at your log, the source code and the related changes, I built a possible explanation:

Since commit 4d87728 the get_configure_xfields function calls to encode, and before that it removes some options that encode does not know, including {sql,_} and {rsm,_}

Your error mentions an unknown option called {odbc,_}, which was used some years ago instead of sql, and was renamed in commit 1aae8a9

So, maybe you used a version older than ejabberd 16.04, which used {odbc,_} in pubsub options, and newest ejabberd versions are not able to handle that old content?

If that's the case, the first thing to look is why your database still contains old {odbc,_}... was there some automatic or manual process to update it?

A dirty workaround in your case would be to let ejabberd handle that:

diff --git a/src/mod_pubsub.erl b/src/mod_pubsub.erl
index 13b44b3ec..eb00e3829 100644
--- a/src/mod_pubsub.erl
+++ b/src/mod_pubsub.erl
@@ -3446,6 +3446,7 @@ get_configure_xfields(_Type, Options, Lang, Groups) ->
       lists:filtermap(
 	fun({roster_groups_allowed, Value}) ->
 		{true, {roster_groups_allowed, Value, Groups}};
+	   ({odbc, _}) -> false;
 	   ({sql, _}) -> false;
 	   ({rsm, _}) -> false;
 	   (_) -> true

[di72nn]

Thanks a lot for your answer!

So, maybe you used a version older than ejabberd 16.04 ...

Yep, this installation dates back at least to 2015.

which used {odbc,_} in pubsub options

There are indeed some nodes like that:

> select count(*) from pubsub_node_option where name = 'odbc';
+----------+
| count(*) |
+----------+
|       16 |
+----------+

There are also nodes with name = 'sql', but I guess that's expected.

If that's the case, the first thing to look is why your database still contains old {odbc,_}... was there some automatic or manual process to update it?

I think I always followed the upgrade procedure, but I can't say that's impossible that I missed something along the way.

A dirty workaround in your case would be to let ejabberd handle that

Would ejabberd be able to handle that correctly? Or maybe I should update it in the DB?

[badlop]

Looking at the release notes ( https://www.process-one.net/blog/ejabberd-16-04/ ), no change was required in the databases, I guess the change was done so ejabberd handled "odbc" and "sql"... but newest code didn't consider that.

Would ejabberd be able to handle that correctly? Or maybe I should update it in the DB?

Better if you update your database, so you don't depend on source code workarounds. Remember to backup database first, in case of troubles :)

[di72nn]

Updated the values in the database. The error is gone, OMEMO seems to work fine.

Thanks a lot!