Cannot reproduce Leave Conversation bug?

MySiteGuy

Well-known member
Affected version
2.2.5
Okay, this happens with both my import tools and Xenforo's stock importer, so I'm filing this as a possible Xenforo bug, not the importer.

I imported a large forum from vB 3.8.x to XF 2.2.5. Any conversations made after the import, the user can leave. Any conversation made before the import they cannot leave. This includes admins who have every permission except two-step set to Yes. This happens with either Accept or Ignore option when leaving.

I checked the xf_conversation_recipient table, and the recipient_state is properly set to 'deleted' or 'deleted_ignore'. But the conversation still shows up in the inbox.

I don't know if this is recent or been an issue for a long time, it is the first time it has been reported to me in countless imports.
 
I'm not currently able to envisage a situation where this would be technically possible so there would appear to be something not quite right with the report but I'm not sure what it is.

The code is quite clear, once you've picked the accept/ignore option - if it exists - we pass that value into the recipient state of the xf_conversation_recipient table.

So my first hunch was that if the recipient state isn't changing then actually it means there is no recipient record. However you say that the recipient record exists and you have confirmed that it contains the correct value.

If that's the case, then the conversation should no longer appear in the list for the person who left the conversation.

My only possible shot in the dark is if the owner_user_id field in the xf_conversation_user table doesn't match up with the correct user in the xf_conversation_recipient table.

But even in that case, I'm unsure how you'd find a record that indicates the process worked in the xf_conversation_recipient table. The default importers take care of this so, again, I'm not sure how things would get into this state.

At this moment in time we'll probably need a more concrete example, perhaps a test database or access to a test install with the database so we can verify this ourselves and see what's happening to the data.
 
I'll investigate. I suspect an issue with the source database, because since this issue came up I can't replicate it with any imports of other databases.
 
Top Bottom