I made a change in my local copy of watchflakes so it won't reopen in this case. #57900 (comment) posted but not reopened. Seems working.
(I forgot to add the "not reopening" message...)

@cherrymui watchflakes appears to have just reopened a bunch of issues. For example this one:
https://go.dev/issue/57888#event-8356641212

I think the reason is that these were closed as a dupe, before the actual fix. Is that right?

I've noticed that, because the watchflakes patterns by default don't have a date bound, watchflakes tends to reopen old issues for unrelated new regressions, as in #60368 (comment).

If you know to look for it, you can manually edit the pattern to add date <= <date of fix CL> when you close the issue. But that step is a little subtle to remember, and it shouldn't be necessary to manually edit the pattern for every single issue we fix.

I think a better behavior for closed issues would probably be:

1. Continue to post matches, without reopening the issue, for failures where either the go commit timestamp or the subrepo commit timestamp is older than the timestamp at which the issue was last closed.
2. Never post a match for a log where both the go commit timestamp and the subrepo commit timestamp (if any) are after the timestamp at which the issue was last closed.
   • Instead, file a new issue with a default pattern. If it turns out to be a duplicate, we can manually reopen the old issue, close the new one as a duplicate, and remove the duplicate from the “Test Flakes” project, which should cause the new logs to once again be posted to the old (reopened) issue.

Just a note: perhaps the new issue should mention the existing closed issue, to make it easier for people to notice the possible duplication.