After fixing SKARA-1148, there are still some emails that aren't being posted as comments in PRs. One such example is:
https://mail.openjdk.java.net/pipermail/openjfx-dev/2021-July/031314.html
https://github.com/openjdk/jfx/pull/579
This time the cause is Skara failing to piece together the conversation correctly for this email. Skara needs to resolve a conversation back to the initial RFR email in order to figure out which PR it belongs to.
In the case above, there are missing emails in the archive, or rather, there are emails that Skara tried to send, and that are then being referenced in the In-Reply-To header of later emails. When Mbox.java resolves conversations, it only looks at the In-Reply-To header, which has the ID of the direct parent in the conversation, so if an email in this chain is missing, resolving fails. The email archive linked above only has 5 mails in this thread (including the one Kevin wrote manually), while Skara has stored 7 mails in its internal archive, which are all generated by Skara, so 3 are missing.
Luckily, the emails have a fallback header called References, which lists all ancestors in the conversation. To properly handle missing emails, we need to fall back on this References field and find the last ID in the list that actually exists.
This is obviously what pipermail does when reconstructing conversations in the thread view: https://mail.openjdk.java.net/pipermail/openjfx-dev/2021-July/thread.html#31279
https://mail.openjdk.java.net/pipermail/openjfx-dev/2021-July/031314.html
https://github.com/openjdk/jfx/pull/579
This time the cause is Skara failing to piece together the conversation correctly for this email. Skara needs to resolve a conversation back to the initial RFR email in order to figure out which PR it belongs to.
In the case above, there are missing emails in the archive, or rather, there are emails that Skara tried to send, and that are then being referenced in the In-Reply-To header of later emails. When Mbox.java resolves conversations, it only looks at the In-Reply-To header, which has the ID of the direct parent in the conversation, so if an email in this chain is missing, resolving fails. The email archive linked above only has 5 mails in this thread (including the one Kevin wrote manually), while Skara has stored 7 mails in its internal archive, which are all generated by Skara, so 3 are missing.
Luckily, the emails have a fallback header called References, which lists all ancestors in the conversation. To properly handle missing emails, we need to fall back on this References field and find the last ID in the list that actually exists.
This is obviously what pipermail does when reconstructing conversations in the thread view: https://mail.openjdk.java.net/pipermail/openjfx-dev/2021-July/thread.html#31279