Design issue Pseudo-duplicate messages on reply (rare)

[Xon]

Rather rarely, I've seen the "more new messages" link after replying to a thread will fetch the just added post. Which results in the same message being appended to the thread twice.

There is actually only one reply, but it looks like two.

I suspect this is caused by time-skew inside the VM, since XenForo_ControllerPublic_Thread::_getNewPosts takes a timestamp which can possibly be off by 1, on a second boundary depending on how time sync works, and if the web requests are between nodes.

 

[Mike]

I'm not really seeing an obvious cause for this, possibly short of race conditions (or more correctly, requests finishing in a different order). The time stamps used here should be the timestamp of elements as they're stored in the database, so I don't think clock differences between servers should directly cause issues, or am I misunderstanding what you're reporting?

 

[Xon]

I'm not really seeing an obvious cause for this, possibly short of race conditions (or more correctly, requests finishing in a different order). The time stamps used here should be the timestamp of elements as they're stored in the database, so I don't think clock differences between servers should directly cause issues, or am I misunderstanding what you're reporting?

The post's timestamp is taken from XenForo_Application::$time which is set on the start of a request and not when the content is inserted. But yes, requests finishing in a different order would likely explain it.

My thinking, was the unix timestamp is only accurate to the second so if the clocks where out of sync when one was near a second boundary it might explain the behaviour. But I only did a cursory look into it, last month.

It would be nice if the DataWriters could actually execute now() on the SQL server itself to populate the default value rather than in code before doing the insert.

 

[Mike]

I think we may just need to chalk this up to a design issue if it is down to requests returning in a slightly different order.

On a side note, the time "fixing" is mostly about consistency across a request. As a somewhat random example, calling time() directly (or some other live source) could theoretically lead to a thread creation date being different than the first post. There does need to be a balance and I take the point about time skew between web servers.