[sivakumar-mahalingam]

Why are the changes needed?

The issue-assignment workflow used the additive addAssignees API for every take comment. As a result, multiple users could be assigned when they commented take on the same issue.

The workflow should assign only the first user who claims an unassigned issue. Subsequent take comments must not change its assignees.

Close #4447.

Brief change log

• Fetch the latest issue state and ignore take comments when the issue is already assigned.
• Find the earliest exact take comment and assign only its author.
• Prevent concurrent workflow runs from assigning multiple users.
• Await the GitHub assignment API call so failures are reported.
• Update CONTRIBUTING.md to document the first-claim behavior.

How was this patch tested?

• Tested the embedded workflow script with mocked GitHub API scenarios covering the first claim, subsequent claims, an already-assigned issue, and concurrent claims.
• Add screenshots for manual tests if appropriate (not applicable).
• Ran actionlint .github/workflows/take.yml.
• Ran git diff --check.
• Ran ./mvnw validate successfully for all 33 modules.

Documentation

• Does this pull request introduce a new feature? no
• If yes, how is the feature documented? not applicable

[sivakumar-mahalingam]

take

[klion26]

@sivakumar-mahalingam Thanks for the improvement! Does this mean

1. If there is some one took the issue already, the following take would not take any side effect
2. If the assignee has been unassigned for some reason(maybe don't have enough time), the following take can assign the issue to him/her who comment
3. If there are concurrent take comments, the first one win.

And another question, could you please share some pic anywhere, so that we can confirm the behavior? if you need someone else to comment another take, please ping me.

[sivakumar-mahalingam]

Hi @klion26 thanks for reviewing this and for pointing out the unassignment case.

1. If the issue already has an assignee, another take comment will currently assign it to both users.
2. If the assignee has been unassigned, the following take can assign the issue to him/her who comment 'take'. This behavior is unchanged.
3. For an issue with no previous claim, currently concurrent take comments are assigned to both users. The pr resolves deterministically and the first comment wins.

This pr raised, as this happened in #4268

[klion26]

What will happen for the following case?

1. Alice take the issue`
2. Alice was unassigned because some reason(maybe she doesn't have time for now)
3. Now the issue has no assignees
4. What would happen if Bob comment take happen?

Seems the take in step 4 would not assign the issue to Bob? We search the previous comment here, as the take comment left by Alice is still there

[sivakumar-mahalingam]

Thanks, you are correct. With the previous implementation, Bob would not be assigned because Alice's old take comment would remain the first take comment in the issue history.

I have updated the workflow to use the issue timeline. The latest unassigned event now starts a new claim period, so the behavior is:

1. Alice comments take and is assigned.
2. Alice is unassigned.
3. Bob comments take.
4. Bob is assigned because his comment is the first take after the latest unassignment.

If multiple users comment take during the same unassigned period, the first comment wins. If the issue already has an assignee, later take comments have no effect.

#4447 defines the expected first-comment-wins behavior, and #4268 is the issue where multiple assignees exposed the original problem.

I also updated CONTRIBUTING.md and tested initial assignment, existing assignment, re-claiming after unassignment, and concurrent claims.

[klion26]

@sivakumar-mahalingam Thanks for the reply, I added a inline comment, please take a look at it.

For the question in my last comment, just want to verify the change here is what we want, could you please give an issue link which shows that the change logic here is what we want. thanks