{"thread":{"id":"62112","subject":"[PATCH] t9001: use a more distinct fake BugID","startedAt":"2024-09-15T11:31:17Z","lastAt":"2024-09-16T07:27:40Z","messageCount":2,"participants":["Jeff King","Patrick Steinhardt"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"502804","messageId":"20240915113115.GA2019070@coredump.intra.peff.net","threadId":"62112","inReplyTo":null,"subject":"[PATCH] t9001: use a more distinct fake BugID","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2024-09-15T11:31:15Z","receivedAt":"2024-09-15T11:31:17Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"In the test \"cc list is sanitized\", we feed a commit with a variety of\ntrailers to send-email, and then check its output to see how it handled\nthem. For most of them, we are grepping for a specific mention of the\nheader, but there's a \"BugID\" header which we expect to be ignored. We\nconfirm this by grepping for \"12345\", the fake BugID, and making sure it\nis not present.\n\nBut we can be fooled by false positives! I just tracked down a flaky\ntest failure here that was caused by matching this unrelated line in the\noutput:\n\n <20240914090449.612345-1-author@example.com>\n\nwhich will change from run to run based on the time, pid, etc.\n\nIdeally we'd tighten the regex to make this more specifically, but since\nthe point is that it _shouldn't_ be mentioned, it's hard to say what the\nright match would be (e.g., would there be a leading space?).\n\nInstead, let's just choose a match that is much less likely to appear.\nThe actual content of the header isn't important, since it's supposed to\nbe ignored.\n\nSigned-off-by: Jeff King \n---\nI guess this is fairly unlikely, as re-running the test with --stress\ndidn't reproduce after a few hundred attempts. Back of the envelope, I\nguess any 5-digit sequence has a 1-in-10^5 chance of matching our\ntarget. There are 2 in chances in a 6-digit pid. Some in the date, but\nas there's no December 34th or hour 34, you're limited to a few specific\ntimes like 01:23:45 (or at 11am), 12:34:5x, or perhaps 23:45 on the 1st,\n11th, or 21st of the month.\n\nSo I think I just got really unlucky, but after spending several minutes\ndebugging, I wouldn't want to wish it on anybody else. ;)\n\n t/t9001-send-email.sh | 4 ++--\n 1 file changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh\nindex df5336bb7e..e2430f7bfa 100755\n--- a/t/t9001-send-email.sh\n+++ b/t/t9001-send-email.sh\n@@ -1324,7 +1324,7 @@ test_expect_success $PREREQ 'cc list is sanitized' '\n \tReviewed-by: Füñný Nâmé \n \tReported-by: bugger on Jira\n \tReported-by: Douglas Reporter [from Jira profile]\n-\tBugID: 12345\n+\tBugID: 12345should-not-appear\n \tCo-developed-by: \"C. O. Developer\" \n \tSigned-off-by: A. U. Thor \n \tEOF\n@@ -1337,7 +1337,7 @@ test_expect_success $PREREQ 'cc list is sanitized' '\n \" \" actual-show-all-headers &&\n \ttest_grep \"^(body) Ignoring Reported-by .* bugger on Jira\" actual-show-all-headers &&\n \ttest_grep \"^(body) Adding cc: Douglas Reporter \" actual-show-all-headers &&\n-\ttest_grep ! \"12345\" actual-show-all-headers &&\n+\ttest_grep ! \"12345should-not-appear\" actual-show-all-headers &&\n \ttest_grep \"^(body) Adding cc: \\\"C. O. Developer\\\" \" actual-show-all-headers &&\n \ttest_grep \"^(body) Adding cc: \\\"A. U. Thor\\\" \" actual-show-all-headers\n '\n-- \n2.46.1.893.gc4b01a7614\n"},{"id":"502831","messageId":"Zufd4BmUu_fRBBrd@pks.im","threadId":"62112","inReplyTo":"20240915113115.GA2019070@coredump.intra.peff.net","subject":"Re: [PATCH] t9001: use a more distinct fake BugID","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2024-09-16T07:27:36Z","receivedAt":"2024-09-16T07:27:40Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Sun, Sep 15, 2024 at 07:31:15AM -0400, Jeff King wrote:\n> In the test \"cc list is sanitized\", we feed a commit with a variety of\n> trailers to send-email, and then check its output to see how it handled\n> them. For most of them, we are grepping for a specific mention of the\n> header, but there's a \"BugID\" header which we expect to be ignored. We\n> confirm this by grepping for \"12345\", the fake BugID, and making sure it\n> is not present.\n> \n> But we can be fooled by false positives! I just tracked down a flaky\n> test failure here that was caused by matching this unrelated line in the\n> output:\n> \n> <20240914090449.612345-1-author@example.com>\n> \n> which will change from run to run based on the time, pid, etc.\n> \n> Ideally we'd tighten the regex to make this more specifically, but since\n> the point is that it _shouldn't_ be mentioned, it's hard to say what the\n> right match would be (e.g., would there be a leading space?).\n> \n> Instead, let's just choose a match that is much less likely to appear.\n> The actual content of the header isn't important, since it's supposed to\n> be ignored.\n> \n> Signed-off-by: Jeff King \n> ---\n> I guess this is fairly unlikely, as re-running the test with --stress\n> didn't reproduce after a few hundred attempts. Back of the envelope, I\n> guess any 5-digit sequence has a 1-in-10^5 chance of matching our\n> target. There are 2 in chances in a 6-digit pid. Some in the date, but\n> as there's no December 34th or hour 34, you're limited to a few specific\n> times like 01:23:45 (or at 11am), 12:34:5x, or perhaps 23:45 on the 1st,\n> 11th, or 21st of the month.\n> \n> So I think I just got really unlucky, but after spending several minutes\n> debugging, I wouldn't want to wish it on anybody else. ;)\n\nHeh, unlucky indeed. In any case, the change makes sense to me, thanks!\n\nPatrick\n"}]}