xavi/dino/libdino/src/service/history_sync.vala, branch masterFork of GTK3 Dino with experimental features.
https://gitea.privatedns.org/xavi/dino/atom?h=master2026-04-11T22:40:37+00:00history_sinc.vala: Do not ask 'before' ID on timestamp range2026-04-11T22:40:37+00:00Xavier Del Campo Romeroxavi92@disroot.org2026-04-11T22:40:37+00:00urn:sha1:d69700b3402ccb81984c2c269bb2edbb5f3fbc10
According to their devs, for some reason some servers like Prosody
dislike receiving an archive query with *both* a timestamp range and a
'before' ID, returning an item-not-found error in such case. An example
query is shown below.
Instead, now the 'before' ID is left empty, which seems to have restored
the expected behaviour.
<iq id='redacted' type='set' to='redacted'>
<query xmlns='urn:xmpp:mam:2' queryid='redacted'>
<x xmlns='jabber:x:data' type='submit'>
<field type='hidden' var='FORM_TYPE'>
<value>
urn:xmpp:mam:2
</value>
</field>
<field var='start'>
<value>
2026-04-11T02:25:00Z
</value>
</field>
<field var='end'>
<value>
2026-04-11T19:41:12Z
</value>
</field>
</x>
<set xmlns='http://jabber.org/protocol/rsm'>
<max>
20
</max>
<before>
redacted
</before>
</set>
</query>
</iq>
Improve history sync2026-02-10T22:40:46+00:00Marvin Wgit@larma.de2023-03-20T21:37:18+00:00urn:sha1:a859694a64ec3e5481e8f5051187587ecd4c3ebf
- Ensure we fully fetch desired history if possible (previously, duplicates
from offline message queue could hinder MAM sync)
- Early drop illegal MAM messages so they don't pile up in the pending queue
waiting for their query to end (which it never will if they were not
requested in first place).
Fixes #1386
Check XmppStream against null2023-10-09T14:38:02+00:00Xavier Del Campo Romeroxavi.dcr@tutanota.com2023-10-04T13:43:31+00:00urn:sha1:e1fd11775c7d275dd57d7d9202e88ac5173bbeef
Most of the calls to stream_interactor.get_stream(account) were already
doing null checks, but there were still some missing.
history_sync.vala: Remove noisy debug2023-10-09T12:09:00+00:00Xavier Del Campo Romeroxavi.dcr@tutanota.com2023-10-03T07:16:11+00:00urn:sha1:0f3d7e27ceb37a0946cd319370f151f22e02b25dImprove history sync under load2023-10-05T12:32:06+00:00Marvin Wgit@larma.de2023-02-06T20:13:33+00:00urn:sha1:55374331bec0d79fc23d2b1291ed544b0b3d4094Add priority for and allow cancellation of outgoing stanzas2023-10-05T12:32:06+00:00Marvin Wgit@larma.de2023-01-31T14:13:12+00:00urn:sha1:7a38a3867446221032ac8111be8c6d752ef3ccd4MAM: Fix latest range not being stored in db if it contained a duplicate2023-10-05T12:32:05+00:00fiaxhgit@lightrise.org2023-01-16T16:24:58+00:00urn:sha1:202ef664fb6fd86f2ddea57a588b64e130e481d1Fix compiler warnings2023-10-05T12:32:04+00:00fiaxhgit@lightrise.org2022-11-26T21:26:25+00:00urn:sha1:6c5ec41beb126698fb096931a5da6cd5df0cecbbMAM: Fix processing after range was fetched completely, fix merging of ranges2023-10-05T12:32:04+00:00fiaxhgit@lightrise.org2022-12-20T18:51:38+00:00urn:sha1:c7ff1d6bea5d8bd1d07179a68d2dae3910787fc0Fix some MAM issues2023-10-05T12:32:04+00:00fiaxhgit@lightrise.org2022-11-20T21:12:38+00:00urn:sha1:5a8bccb454197553ec81410ed380b1a9c6db8af7
- Messages from MUCs weren't added to their respective MUC MAM ranges,
thus re-fetched on rejoin.
- The earliest ('first') message of a mam page was used to update the
to_id, but it should have been 'last'; also the other way around.
- Duplicates weren't detected properly.