Summary
Since #97, the action replaces a PR's entire label set via PUT /issues/{n}/labels instead of adding its label via POST.
The GitHub labels API treats these differently on /issues/{n}/labels:
POST adds the labels in the body and leaves all others untouched.PUT replaces the issue's entire label set, removing anything not in the body.
Because $comma_separated_labels is derived from an earlier snapshot GET, any label applied to the PR after that read (by another workflow or bot) is absent from the body and is therefore deleted by the PUT. This is a read-modify-write race whenever a second actor labels the same PR concurrently.
Suggested fix
Keep the add operation additive and remove only the stale size labels explicitly, rather than replacing the whole set. Roughly:
That resolves the accumulation issue #97 targeted without touching labels the action does not own.
Summary
Since #97, the action replaces a PR's entire label set via
PUT /issues/{n}/labelsinstead of adding its label viaPOST.The GitHub labels API treats these differently on
/issues/{n}/labels:POSTadds the labels in the body and leaves all others untouched.PUTreplaces the issue's entire label set, removing anything not in the body.Because
$comma_separated_labelsis derived from an earlier snapshot GET, any label applied to the PR after that read (by another workflow or bot) is absent from the body and is therefore deleted by thePUT. This is a read-modify-write race whenever a second actor labels the same PR concurrently.Suggested fix
Keep the add operation additive and remove only the stale size labels explicitly, rather than replacing the whole set. Roughly:
POST /issues/{n}/labelswith just the new size label (additive, as in fix: use the add label API rather than patching the entire issue #89), andDELETE /issues/{n}/labels/{name}.That resolves the accumulation issue #97 targeted without touching labels the action does not own.