[Intermediate]: Investigate why code rabbit plan is running 4x per new issue

[exploreriii]

🧩 Intermediate Contributors

This issue is intended for contributors who already have some familiarity with the
Hiero Python SDK codebase and contribution workflow.

You should feel comfortable:

• navigating existing source code and examples
• understanding SDK concepts without step-by-step guidance
• following the standard PR workflow without additional onboarding

If this is your very first contribution to the project, we recommend starting with a few
Good First Issues before working on this one.

🐞 Problem Description

Code rabbit, out AI reviewer and planner, is running what seems at first sight, too many times

https://github.com/hiero-ledger/hiero-sdk-python/actions/workflows/bot-coderabbit-plan-trigger.yml

You can see the action is running 4 times per issue created, is this necessary?

I get an email notification each time, so it would be nice if this was 1 or 0 emails

💡 Expected Solution

Debug
.github/workflows/bot-coderabbit-plan-trigger.yml
https://github.com/hiero-ledger/hiero-sdk-python/actions/workflows/bot-coderabbit-plan-trigger.yml

identify why it runs so many times
identify if something might be more efficient, without changing functionality too much

🧠 Implementation Notes

Investigative work!

✅ Acceptance Criteria

To merge this issue, the pull request must:

• Fully address the problem described above
• Follow existing project conventions and patterns
• Include tests or example updates where appropriate
• Pass all CI checks
• Include a valid changelog entry
• Use DCO and GPG-signed commits

📚 Additional Context or Resources

• SDK Developer Docs
• SDK Developer Training

[github-actions]

@coderabbitai plan

[coderabbitai]

Coding Plan

Approach

Fix the CodeRabbit plan trigger workflow that currently runs 4 times per issue (once per qualifying label plus the opened event), causing 4 email notifications. The solution adds event action awareness to distinguish between opened and labeled events, ensuring the workflow runs only once per logical event while maintaining functionality for both issue creation and label addition scenarios.

Observations

The repository uses GitHub Actions for automation, with 27+ workflow files following consistent patterns including concurrency controls, label-based filtering, and comment marker deduplication. The CodeRabbit workflow triggers on issue events (opened, labeled) and uses a JavaScript script to post plan trigger comments. The workflow already implements concurrency grouping and script-level deduplication, but still executes multiple times due to how GitHub fires separate events for each label.

Based on GitHub's event model and web search findings, when an issue is created with multiple labels (or labels are added rapidly), GitHub fires one event per label plus the opened event. If an issue has 3 qualifying labels (beginner, intermediate, advanced) plus the opened event, that's 4 workflow runs.

Assumptions

Assumption 1: Why does the workflow run 4 times per issue?

Options Considered:

• Accept multiple runs and rely only on script-level deduplication
• Remove the labeled trigger entirely (only run on opened)
• Add event action awareness to distinguish between opened vs labeled events
• Change concurrency settings to cancel in-progress runs

Chosen Option: 3

Rationale: Event action awareness is the best solution because it maintains full functionality (runs on both opened and labeled events) while preventing duplicate runs by checking the specific event context—for "opened" events run once regardless of label count, for "labeled" events only run if the specific label being added is a target label.

💡 User Tips

Regenerate the plan with different choices with @coderabbitai <feedback>.

Implementation Steps

Phase 1: Update Workflow Event Filtering

Add event action awareness to the workflow conditional to prevent multiple executions when issues have multiple qualifying labels.

Task 1: Enhance the workflow conditional logic

Update the conditional check in .github/workflows/bot-coderabbit-plan-trigger.yml to differentiate between event types

• Modify the job-level if: statement to check github.event.action and handle two distinct cases:
  • For opened action: Check if the issue has any of the target labels using contains(github.event.issue.labels.*.name, 'label-name')
  • For labeled action: Check if the specific label being added (github.event.label.name) matches one of the target label names (beginner, intermediate, advanced) in a case-insensitive manner
• Structure the conditional using logical operators to ensure only one execution occurs per logical event (either issue opened with qualifying labels, or a qualifying label being added)

Task 2: Strengthen concurrency controls

Update the concurrency configuration to follow the pattern established in other issue-handling workflows

• Change cancel-in-progress: false to cancel-in-progress: true in the concurrency block
• This provides additional protection against edge cases where multiple runs might still be queued
• Aligns with the pattern used in bot-advanced-check.yml and other issue workflows

🤖 Prompt for AI agents

Update the CodeRabbit plan trigger workflow to prevent duplicate executions when
issues have multiple qualifying labels.

In `.github/workflows/bot-coderabbit-plan-trigger.yml`:
- Add event action awareness to the job-level `if:` conditional
- For `opened` action: check if the issue has any target labels (beginner,
intermediate, advanced)
- For `labeled` action: check if the specific label being added matches a target
label
- Use logical operators to ensure only one execution per logical event
- Change `cancel-in-progress: false` to `cancel-in-progress: true` in the
concurrency block

Phase 2: Validation and Documentation

Ensure the changes work as expected and document the behavior for future maintainers.

Task 1: Add inline documentation

Document the event handling logic in the workflow file

• Add a comment block above the conditional explaining why the event action check is necessary
• Explain that GitHub fires separate events for each label, and this check prevents duplicate runs
• Reference this issue number in the comment for historical context

Task 2: Update changelog

Create a changelog entry describing the fix

• Add an entry to the changelog file following the project's changelog conventions
• Categorize as a bug fix or improvement
• Describe the change as "Fixed CodeRabbit plan trigger workflow to run once per issue instead of multiple times when issues have multiple qualifying labels"

🤖 Prompt for AI agents

Document the workflow changes and update project changelog.

In `.github/workflows/bot-coderabbit-plan-trigger.yml`:
- Add comment block above the conditional explaining the event action check
- Explain that GitHub fires separate events for each label
- Reference the issue number for historical context

In the changelog file:
- Add entry as a bug fix/improvement
- Describe: "Fixed CodeRabbit plan trigger workflow to run once per issue
instead of multiple times when issues have multiple qualifying labels"

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

Update the CodeRabbit plan trigger workflow to prevent duplicate executions when
issues have multiple qualifying labels.

In `.github/workflows/bot-coderabbit-plan-trigger.yml`:
- Add event action awareness to the job-level `if:` conditional
- For `opened` action: check if the issue has any target labels (beginner,
intermediate, advanced)
- For `labeled` action: check if the specific label being added matches a target
label
- Use logical operators to ensure only one execution per logical event
- Change `cancel-in-progress: false` to `cancel-in-progress: true` in the
concurrency block
===============================================================================

Task: 2

Document the workflow changes and update project changelog.

In `.github/workflows/bot-coderabbit-plan-trigger.yml`:
- Add comment block above the conditional explaining the event action check
- Explain that GitHub fires separate events for each label
- Reference the issue number for historical context

In the changelog file:
- Add entry as a bug fix/improvement
- Describe: "Fixed CodeRabbit plan trigger workflow to run once per issue
instead of multiple times when issues have multiple qualifying labels"

💡 Iterate on the plan with: @coderabbitai <feedback>

Example Feedback
- @coderabbitai You can skip phase 3. Add a simple unit test case for phase 2.
- @coderabbitai For assumption 1 go ahead with option 3 and replan.

---

💬 Have feedback or questions? Drop into our discord!

[cheese-cakee]

Hii @exploreriii !

I've investigated this issue. Here's my analysis:

Root Cause

The workflow triggers on both opened and labeled events:

on:
  issues:
    types: [opened, labeled]

When a new issue is created using a template (e.g., intermediate issue template), multiple labels get added sequentially. Each label addition fires a labeled event, and the workflow runs because the if condition checks if the issue has any beginner/intermediate/advanced label, not whether the newly added label is one of those.

So for a typical issue with 3-4 labels, the workflow runs 4 times (1 for opened + 3 for each labeled event).

The script already has duplicate detection (hasExistingCodeRabbitPlan()), so the comment only posts once, but the workflow still executes 4 times,consuming CI minutes and generating email notifications.

Proposed Solutions

Option 1: Remove opened event, keep only labeled

on:
  issues:
    types: [labeled]

Option 2: Only trigger when the newly added label is beginner/intermediate/advanced

if: >
  github.event.action == 'labeled' && 
  (github.event.label.name == 'beginner' || 
   github.event.label.name == 'intermediate' || 
   github.event.label.name == 'advanced')

My question is which approach would you prefer? I wanted to confirm before implementing and if any better approach exists in your opinion. Thank you!

[exploreriii]

Is it true that a workflow only notifies by email, if it skips or fails? success is not notified?
In which case, you could just filter things out in the script, rather than the workflow itself?

I'd assume option 1 is not great because there are still often multiple labels
Option 2 is better, as assume these are never combined, however, will it email with skipped?

[cheese-cakee]

1.whether GitHub only emails on skip/fail, not success,depends on the user's notification settings:

By default, GitHub sends workflow run notifications for failed runs, not successful ones.
Skipped workflows (where the if: condition fails) do not generate email notifications
one can customize this in Settings → Notifications
So if we make the workflow skip early via if: condition, one should not get email notifications.

2. If we filter in the script, the workflow still runs 4 times, it just exits early. But if we filter in the workflow if: condition, the workflow skips entirely.
   However, skipping via if: is cleaner because:
   No CI minutes consumed
   Cleaner action history
   No email notifications