Owntracks not respecting correct sequence when "flushing" cached locations ?

[boogymantoo]

Upfront apologies: the behavior that I describe here-below was observed during a recent test (June 12, 2021), but I do not know which OT version was installed on the device that behaved like this.

After long sessions of debug and analysis, this is what we observed (with pretty high degree of certainty):

• the device enters a zone with insufficient network reception, so OT starts caching its locations
• this situation persists for quite a while - about 30 minutes
• when the device finally recovers network reception, it starts "flushing" the cached messages one by one
• BUT new location messages, which are taken during the period that the "flushing" happens, are sent out in real-time, in-between the cached messages

My question is simply whether anyone:

• has experienced this same or a comparable behavior?
• can confirm this (if so, is it considered a bug? and if yes, in which version?)

Many thanks,
Chris.

[growse]

Huh, interesting. This shouldn't happen.

Any new messages that get created in the code (either by the device surfacing a new location, or an explicit request to publish) get put at the end of a queue, which is being drained by a separate worker. So when you get reconnected, the worker should start to drain from the head of the queue and post messages to the network in the order they were added to the queue - new messages should be added to the tail, so only get sent after all the others are sent.

I'll try and jig up a test where I give the app a large list of locations to send, and then purposefully make the network slow so that the queue drains slowly. In move mode, that should then generate locations as the queue is draining and we should be able to check the behaviour.

[boogymantoo]

Huh, interesting. This shouldn't happen.

I'll try and jig up a test where I give the app a large list of locations to send, and then purposefully make the network slow so that the queue drains slowly. In move mode, that should then generate locations as the queue is draining and we should be able to check the behaviour.

Many thanks Andrew. During the field-test where we observed this this, there were about 50 owntracks devices active - a mix of Android and iPhone. From the resulting location messages I am pretty sure this behavior happened on an Android device, but I am not 100% sure. I will contact the participant "behind" the device ID in question.

Best regards,
Chris.

[boogymantoo]

Huh, interesting. This shouldn't happen.

From the resulting location messages I am pretty sure this behavior happened on an Android device, but I am not 100% sure. I will contact the participant "behind" the device ID in question.

The participant has confirmed that he's using an Android phone, with owntracks version 2.3.0 installed.

[growse]

Ok, I'll try and replicate.