fix(main): await functions

[tcely]

No description provided.

[qodo-code-review]

Review Summary by Qodo

Add workflow_dispatch event support for manual sweeps

✨ Enhancement

Walkthroughs

Description

• Add support for workflow_dispatch event trigger
• Enable manual sweep execution alongside scheduled runs

Diagram

flowchart LR
  A["GitHub Event"] --> B{"Event Type Check"}
  B -->|schedule or workflow_dispatch| C["Execute sweep()"]
  B -->|issue_comment| D["Execute unmark()"]
  B -->|issues| E["Execute removeLabels()"]

Loading

File Changes

1. src/main.ts ✨ Enhancement +1/-1

Add workflow_dispatch event trigger support

• Modified event name condition to include workflow_dispatch trigger
• Allows sweep operation to run on both scheduled events and manual workflow dispatches
• Maintains existing behavior for other event types

src/main.ts

---

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 📎 Requirement gaps (0)

1. Async handlers not awaited ☑ 🐞 Bug ⛯ Reliability

Description

run() invokes noResponse.sweep(), noResponse.unmark(), and noResponse.removeLabels() without
await, so any rejection in those async flows bypasses the surrounding try/catch and may not call
core.setFailed. This can make schedule/workflow_dispatch runs report success while API operations
fail or are incomplete.

Code

src/main.ts[R11-14]

+    if (eventName === 'schedule' || eventName === 'workflow_dispatch') {
     noResponse.sweep()
   } else if (eventName === 'issue_comment') {
     noResponse.unmark()

Evidence

The PR routes workflow_dispatch into the sweep path, but the sweep/unmark/removeLabels calls are
still made without awaiting their returned Promises, so the try/catch around them cannot catch async
failures. The invoked methods are async and contain awaited GitHub API calls, meaning they can
reject asynchronously.

src/main.ts[5-22]
src/no-response.ts[53-79]
src/no-response.ts[81-117]
src/no-response.ts[119-164]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`src/main.ts` calls async methods (`sweep`, `unmark`, `removeLabels`) without `await`. Because of this, Promise rejections from GitHub API calls can bypass the `try/catch` in `run()` and may not mark the action as failed.
### Issue Context
The NoResponse methods are `async` and contain multiple awaited API calls; they return Promises that can reject.
### Fix Focus Areas
- src/main.ts[5-22]
### Implementation notes
- Add `await` before `noResponse.sweep()`, `noResponse.unmark()`, and `noResponse.removeLabels()`.
- Keep error handling consistent so failures end up in `core.setFailed(...)`.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Docs omit workflow_dispatch 🐞 Bug ✓ Correctness

Description

The code now supports running sweeps on workflow_dispatch, but the README still says scheduled
events are required and its workflow examples omit workflow_dispatch. Users following the docs
will miss the manual trigger and may believe on-demand sweeps are unsupported.

Code

src/main.ts[11]

+    if (eventName === 'schedule' || eventName === 'workflow_dispatch') {

Evidence

src/main.ts explicitly treats workflow_dispatch the same as schedule for running a sweep, but
README guidance still documents only schedule as the sweep trigger and states scheduled events are
required.

src/main.ts[11-12]
README.md[12-23]
README.md[38-47]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
README examples and wording still imply sweeps only run via `schedule`, but the action now supports `workflow_dispatch` as well.
### Issue Context
The action routes `workflow_dispatch` into the same sweep code path as `schedule`.
### Fix Focus Areas
- README.md[12-23]
- README.md[38-47]
### Implementation notes
- Add `workflow_dispatch:` under `on:` in the sample workflows.
- Adjust wording like “scheduled event types are required” to include `workflow_dispatch` as an accepted alternative for sweep runs.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

ⓘ The new review experience is currently in Beta. Learn more

[qodo-code-review]

Ask❓

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

Issue description

README examples and wording still imply sweeps only run via schedule, but the action now supports workflow_dispatch as well.

Issue Context

The action routes workflow_dispatch into the same sweep code path as schedule.

Fix Focus Areas

• README.md[12-23]
• README.md[38-47]

Implementation notes

• Add workflow_dispatch: under on: in the sample workflows.
• Adjust wording like “scheduled event types are required” to include workflow_dispatch as an accepted alternative for sweep runs.

Answer:

The code change correctly routes workflow_dispatch into the same sweep path as schedule, but the README still documents sweep runs as “schedule-only”. To fix the review issue, update the README sections called out so the examples and wording reflect either schedule or workflow_dispatch.

What to change

1) README.md [12–23]: Sample workflow on: block

Add workflow_dispatch: alongside schedule: in the example that triggers sweeps.

Example update:

on:
  schedule:
    - cron: "0 0 * * *"
  workflow_dispatch:

If the README currently shows only scheduled sweeps, this makes it clear that users can also trigger a sweep manually from the Actions tab.

2) README.md [38–47]: Wording about required event types

Wherever the README says (or implies) that a sweep requires “scheduled event types” / “schedule is required”, update it to include workflow_dispatch as an accepted alternative.

Suggested wording replacements:

• Replace phrasing like:
  • “Scheduled event types are required”
  • “This action only runs sweeps on schedule”
• With something like:
  • “Sweep runs require either schedule or workflow_dispatch.”
  • “Sweeps can run on a schedule (schedule) or be triggered manually (workflow_dispatch).”

If you want to be extra explicit and match the implementation:

• “The action runs sweep() when triggered by schedule or workflow_dispatch.”

Why this matches the PR behavior

In src/main.ts, workflow_dispatch is now treated identically to schedule:

• if (eventName === 'schedule' || eventName === 'workflow_dispatch') { await noResponse.sweep() }

So the README should reflect that sweeps are no longer “schedule-only”, and that manual dispatch is supported in the sample workflow and in the explanatory text.