M2B adds some emails to another tickets history when unrelated
Opened this issue · 4 comments
Sometimes Mail2Bug will add an new email to the history of an unrelated ticket instead of creating a new ticket.
Interesting; it would be useful if you could share more information in order to understand this. When examining the message headers, for example, are there fields such as conversation ID that may be shared?
They have the same subject, and the same Thread-Topic, and a similar Thread-Index. We are running a support line using Mail2Bug so we often get emails with the same subject, but only occasionally do they end up being processed wrong.
We're also experiencing this. Sometimes a completely unrelated e-mail will get added in some random and very distinct work item. No headers, subjects or ConversationID match.
Log output is not useful at all:
2017-12-01 15:55:17,483 [7] INFO Mail2Bug.Mail2BugEngine [(null)] - Initializing MessageProcessingStrategy
2017-12-01 15:55:17,505 [7] INFO Mail2Bug.MessageProcessingStrategies.SimpleBugStrategy [(null)] - Modifying work item 816 subject: espa<E7>o servidor
2017-12-01 15:55:17,519 [7] INFO Mail2Bug.MessageProcessingStrategies.NameResolver [(null)] - Resolving name for alias/name fabricio/Fabricio Foresti
2017-12-01 15:55:17,528 [7] WARN Mail2Bug.MessageProcessingStrategies.SpecialValueResolver [(null)] - Name resolution failed for sender alias 'fabricio'. Returning display name.
2017-12-01 15:55:18,153 [7] INFO Mail2Bug.Mail2BugEngine [(null)] - Message 'espa<E7>o servidor' processed successfully, moving to next message
The work item 816 was manually created just before we started using M2B. This query returns nothing:
SELECT [StringValue]
FROM [Tfs_DefaultCollection].[dbo].[tbl_WorkItemCustomLatest]
WHERE FieldId = 10665 /* ConversationId */
AND ID = 816 /* Work item */In config we have:
<UseConversationGuidOnly>true</UseConversationGuidOnly>Have no idea how to reproduce this problem. Would be happy to provide more information about it. We are also running a support line on TFS and really need to solve this problem.
Can you try changing the log level to DEBUG in log4net.config and check the logs on repro?
The last time I saw a similar issue, the reason was manually entered values in the ConversationId field in TFS. The matching logic is StartsWith rather than equality, and one-letter/two-letter values in the field could result in inadvertent matches.