Inbox/pagination — part 1 #3827
Conversation
This comment was marked as outdated.
This comment was marked as outdated.
Codecov ReportBase: 83.03% // Head: 83.04% // Increases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## master #3827 +/- ##
=======================================
Coverage 83.03% 83.04%
=======================================
Files 529 529
Lines 33889 33902 +13
=======================================
+ Hits 28141 28153 +12
- Misses 5748 5749 +1
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
This comment was marked as outdated.
This comment was marked as outdated.
NelsonVides
force-pushed
the
inbox/pagination
branch
from
f212153 to
a9d463e
Compare
|
small_tests_24 / small_tests / a9d463e small_tests_25 / small_tests / a9d463e dynamic_domains_pgsql_mnesia_24 / pgsql_mnesia / a9d463e ldap_mnesia_24 / ldap_mnesia / a9d463e dynamic_domains_mysql_redis_25 / mysql_redis / a9d463e ldap_mnesia_25 / ldap_mnesia / a9d463e dynamic_domains_mssql_mnesia_25 / odbc_mssql_mnesia / a9d463e internal_mnesia_25 / internal_mnesia / a9d463e elasticsearch_and_cassandra_25 / elasticsearch_and_cassandra_mnesia / a9d463e pgsql_mnesia_24 / pgsql_mnesia / a9d463e mysql_redis_25 / mysql_redis / a9d463e riak_mnesia_24 / riak_mnesia / a9d463e graphql_roster_SUITE:user_roster:user_invite_accept_and_cancel_subscription{error,
{timeout_when_waiting_for_stanza,
[{escalus_client,wait_for_stanza,
[{client,
<<"bob_user_invite_accept_and_cancel_subscription_871@localhost/res1">>,
escalus_tcp,<0.22653.0>,
[{event_manager,<0.22651.0>},
{server,<<"localhost">>},
{username,
<<"bOb_user_invite_accept_and_cancel_subscription_871">>},
{resource,<<"res1">>}],
[{event_client,
[{event_manager,<0.22651.0>},
{server,<<"localhost">>},
{username,
<<"bOb_user_invite_accept_and_cancel_subscription_871">>},
{resource,<<"res1">>}]},
{resource,<<"res1">>},
{username,
<<"bob_user_invite_accept_and_cancel_subscription_871">>},
{server,<<"localhost">>},
{host,<<"localhost">>},
{port,5222},
{auth,{escalus_auth,auth_plain}},
{wspath,undefined},
{username,
<<"bOb_user_invite_accept_and_cancel_subscription_871">>},
{server,<<"localhost">>},
{password,<<"makrolika">>},
{stream_id,<<"f39077d764063c5c">>}]},
1],
[{file,
"/home/circleci/project/big_tests/_build/default/lib/escalus/src/escalus_client.erl"},
{line,136}]},
{graphql_roster_SUITE,
user_invite_accept_and_cancel_subscription_story,3,
[{file,
"/home/circleci/project/big_tests/tests/graphql_roster_SUITE...pgsql_mnesia_25 / pgsql_mnesia / a9d463e mssql_mnesia_25 / odbc_mssql_mnesia / a9d463e riak_mnesia_24 / riak_mnesia / a9d463e |
NelsonVides
force-pushed
the
inbox/pagination
branch
from
a9d463e to
5d3c85d
Compare
|
small_tests_24 / small_tests / 5d3c85d small_tests_25 / small_tests / 5d3c85d dynamic_domains_pgsql_mnesia_24 / pgsql_mnesia / 5d3c85d ldap_mnesia_24 / ldap_mnesia / 5d3c85d ldap_mnesia_25 / ldap_mnesia / 5d3c85d dynamic_domains_mysql_redis_25 / mysql_redis / 5d3c85d internal_mnesia_25 / internal_mnesia / 5d3c85d pgsql_mnesia_24 / pgsql_mnesia / 5d3c85d elasticsearch_and_cassandra_25 / elasticsearch_and_cassandra_mnesia / 5d3c85d dynamic_domains_mssql_mnesia_25 / odbc_mssql_mnesia / 5d3c85d mysql_redis_25 / mysql_redis / 5d3c85d pgsql_mnesia_25 / pgsql_mnesia / 5d3c85d riak_mnesia_24 / riak_mnesia / 5d3c85d mssql_mnesia_25 / odbc_mssql_mnesia / 5d3c85d |
Currently inbox introduces only the max key of the RSM XEP, and within the inbox form we also allow for setting something equivalent to the RSM’s before and after. But there’s no RSM payload in the iq-fin-result, and also, helper libraries might be used on the client side for more complex pagination, provided full support for RSM is available.
This PR introduces support for points:
Other points in the document might be implemented fully or partially but I haven't taken them into consideration for this PR and are therefore not verified nor tested.
Note that the
countis not introduced, the document specifies that:Also not yet fully perfected is the fact that the UIDs as specified in the document are not unique, currently it is using the integer representation of the timestamp of the inbox row, which can potentially collide. Left is to ensure timestamps are unique, or use a hash of the jid which are known to be unique, though in that case it'd need to make more complex queries to find out about the order by timestamp.
This is for now experimental and therefore not yet fully documented, I plan to do so in a subsequent PR, but it is as of this PR pretty much the requirement I currently have.