Today, a user reported that in a repo which is configured with maintainer approval feature, he added the approved label to the issue but skara bot didn't update the related PR.
From the log, I found skara bot said "[Issue]No activity since last check, not checking again."
When investigating, I guess the scenario likes this. When the bot is evaluating a PR. The bot fetches the issue and the issue only contains label “XXX-fix-request”. Then, the user add "XXX-fix-yes" to issue. So in the end of evaluation, the bot fetches the issue again and calculates the metadata again (at that time, the issue contains label “XXX-fix-request, XXX-fix-yes”). So in the next round, the bot would think that new label “XXX-fix-yes” is already handled, so it will not evaluate the PR again.
But as Erik introduced a cache for IssueTrackerIssue in CheckWorkItem inSKARA-1963. I think the bot shouldn't fetch the issue from JBS again in the end of checkRun. But the bot really did. Then I found that the key of the map(cache) are supposed to be short id of the JBS issue, But in CheckWorkItem#getIssueMetadata, the bot is trying to use the whole id of JBS issue to get the cached data, which will always miss and trigger the remote call.
From the log, I found skara bot said "[Issue]No activity since last check, not checking again."
When investigating, I guess the scenario likes this. When the bot is evaluating a PR. The bot fetches the issue and the issue only contains label “XXX-fix-request”. Then, the user add "XXX-fix-yes" to issue. So in the end of evaluation, the bot fetches the issue again and calculates the metadata again (at that time, the issue contains label “XXX-fix-request, XXX-fix-yes”). So in the next round, the bot would think that new label “XXX-fix-yes” is already handled, so it will not evaluate the PR again.
But as Erik introduced a cache for IssueTrackerIssue in CheckWorkItem in