Fixed New conversation posts not showing until replied to

Groatz

Member
Affected version
2.1
Exactly as per this thread:


This seems to be happening when the conversation just gets over a page boundary, users need to send a message to be able to see the next message even though they do receive a notification.

This bug was in XF2.0 and still present in XF2.1

Regards, Groatz
 
For the cases that happened here, I may need to have the actual conversation IDs that are affected. I can't reproduce this locally, so I can only assume that something in one of the records has an inconsistent count or something.
 
Thanks for sending me details of the Conversation Steve.

I ascertained that some of the record counts were incorrect. Essentially the reply_count field which is used to calculate the number of pages and page boundaries was incorrect.

This has been resolved by virtue of running a Conversations rebuild but of course it doesn't answer the question as to why it happened in the first place.
 
Can say I didn't notice it until the convo hit 200 pages. Not sure that even matters.

For what it is worth, I noticed this issue on someone's XF2.x site earlier this year, in a conversation at around page 7 (IIRC). The conversation's age was probably about 2 weeks old. This occurred elsewhere and not with XenForo.com or my own site.
 
Thanks for sending me details of the Conversation Steve.

I ascertained that some of the record counts were incorrect. Essentially the reply_count field which is used to calculate the number of pages and page boundaries was incorrect.

This has been resolved by virtue of running a Conversations rebuild but of course it doesn't answer the question as to why it happened in the first place.

Let me know if I can do anything, can probably give you access to the Conversation I mentioned in the thread linked in OP of this one.
 
If it's on your own forum you can probably just tell me the result of these queries:
SQL:
SELECT COUNT(*) FROM xf_conversation_message WHERE conversation_id = <CONVERSATION_ID>
SQL:
SELECT reply_count FROM xf_conversation_master WHERE conversation_id = <CONVERSATION_ID>
SQL:
SELECT reply_count FROM xf_conversation_user WHERE conversation_id = <CONVERSATION_ID>
That will prove the counts got skewed like in the case here, at least.
 
Hi Chris,
Yes, we have the exact same problem!
Here are our query results:
SELECT COUNT (*) FROM xf_conversation_message WHERE conversation_id = 4549
1878

SELECT reply_count FROM xf_conversation_master WHERE conversation_id = 4549
1875

SELECT reply_count FROM xf_conversation_user WHERE conversation_id = 4549
1875
1875

Chris, how do you run rebuilding conversation?
 
The count of messages should be one higher than the reply count values (the first message plus X replies).

You can rebuild conversations from Tools > Rebuild caches > Conversation rebuild
 
SQL:
SELECT COUNT(*) FROM xf_conversation_message WHERE conversation_id = <CONVERSATION_ID>
= 771
SQL:
SELECT reply_count FROM xf_conversation_master WHERE conversation_id = <CONVERSATION_ID>

=769
SQL:
SELECT reply_count FROM xf_conversation_user WHERE conversation_id = <CONVERSATION_ID>

=
769
769
769
769
769
769
769
 
SQL:
SELECT COUNT(*) FROM xf_conversation_message WHERE conversation_id = <CONVERSATION_ID>
= 771
SQL:
SELECT reply_count FROM xf_conversation_master WHERE conversation_id = <CONVERSATION_ID>

=769
SQL:
SELECT reply_count FROM xf_conversation_user WHERE conversation_id = <CONVERSATION_ID>

=
769
769
769
769
769
769
769
Those reply_count values should be 770. If you rebuild conversations and run the queries again everything should output correctly.
 
The count of messages should be one higher than the reply count values (the first message plus X replies).

You can rebuild conversations from Tools > Rebuild caches > Conversation rebuild

I can confirm that running a Conversation rebuild fixed our problem and there have been no further reports (so far) from users. Indeed it's not clear why/how they counters became erroneous in the first place.

Regards, Groatz
 
Indeed it's not clear why/how they counters became erroneous in the first place.
That's my primary concern, at this stage. I haven't actually looked into the code yet.

My current working theory is perhaps we're doing some of these updates outside of a transaction, so if the updates were to fail, it may leave the DB partially updated, or similar, but I've not actually looked at the code, yet :)
 
Top Bottom