After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 625920 - Backlog messages are mixed when receiving delayed message
Backlog messages are mixed when receiving delayed message
Status: RESOLVED OBSOLETE
Product: empathy
Classification: Core
Component: Archives
2.29.x
Other Linux
: Normal normal
: 3.2
Assigned To: empathy-maint
Depends on:
Blocks:
 
 
Reported: 2010-08-03 10:29 UTC by Guillaume Desmottes
Modified: 2011-09-06 09:08 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Guillaume Desmottes 2010-08-03 10:29:09 UTC
- Be sure that your XMPP account is offline
- Ask to a friend to send you 2 messages A and B
- Go online
- Empathy displays:
B
A
A
B
Comment 1 Guillaume Desmottes 2010-08-03 11:48:28 UTC
The Duplication is because Empathy is failing to detect that the messages from the backlogs are actually the same as the ones in pending (not acked) yet.
When opening a chat Empathy does the following:

- Ask Logger for the 5 latest messages with this contact.
- Those messages are filtered to discard pending messages. This is done using this crappy heuristic: if the timestamps and bodies are equal then assume they are the same message.
- Once the 5 most recent backlog messages have been displayed display pending messages.

The problem here is that the heuristic is failing because the timestamps don't match.
Empathy uses the timestamp from the Text.Received signal which is define as "A Unix timestamp indicating when the message was received" while the logger uses the message-received key from the Messages interfaces which has the same semantic.

Except that when the message is a delayed one (it has been received while we were offline) the timestamp of the Received signal is the time when the message has been *sent* (we get it from XMPP). So timestamps don't match!

So the problem here is that the semantic of Received's timestamp changes depending if the message has been delayed or not.

I'm not sure what's the best way to fix that. Options include:

a) Fix Gabble to respect the official semantic of Received's timestamp, so always use the time when the message has been *receveid*. That means people using Text won't be able to access to the sending time any more but we could argue they should just use Messages if they care.

b) Move Empathy to the bright Messages future which is something we want to do anyway. But I'd prefer to do that once Messages has become mandatory and implemented in all the CM so I can remove the old API support. Then use the message-received as timestamp as well.

c) Get rid of the crappy heuristic in Empathy and use the unique ID of the message to detect if the backlog is pending or not. This also requiers Messages and we don't really have this unique ID yet (bug #26838)
Comment 2 Emilio Pozuelo Monfort 2011-06-22 15:43:35 UTC
(In reply to comment #1)
> I'm not sure what's the best way to fix that. Options include:
> 
> a) Fix Gabble to respect the official semantic of Received's timestamp, so
> always use the time when the message has been *receveid*. That means people
> using Text won't be able to access to the sending time any more but we could
> argue they should just use Messages if they care.
> 
> b) Move Empathy to the bright Messages future which is something we want to do
> anyway. But I'd prefer to do that once Messages has become mandatory and
> implemented in all the CM so I can remove the old API support. Then use the
> message-received as timestamp as well.
> 
> c) Get rid of the crappy heuristic in Empathy and use the unique ID of the
> message to detect if the backlog is pending or not. This also requiers Messages
> and we don't really have this unique ID yet (bug #26838)

We now require Messages, right? So we can probably fix this if it's still a problem.
Comment 3 Guillaume Desmottes 2011-09-06 09:08:22 UTC
I can't reproduce this with master. I guess we fixed it when porting to TpTextChannel. :)