Add workflow status comment with link on label event and update through run lifecycle

[issuetopr-dev]

Summary

• When the GitHub webhook for the label "I2PR: Resolve Issue" is triggered, we now post an immediate issue comment indicating the workflow has been queued, including a direct link to the Workflow Run page in the app.
• The comment contains a hidden marker () so we can reliably find and update the same comment later.
• The worker orchestrator now passes the BullMQ jobId into the workflow usecase, ensuring the Workflow Run ID matches the jobId so the link is stable.
• The worker orchestrator upserts the same status comment at lifecycle milestones:
  • running: right before the workflow starts
  • completed: after the workflow finishes successfully
  • failed: on errors

Implementation details

• lib/webhook/github/handlers/issue/label.autoResolveIssue.handler.ts
  • Grabs the jobId returned from enqueueing the job.
  • Posts the initial comment with status "queued" and a link to /workflow-runs/{jobId} using NEXT_PUBLIC_BASE_URL (fallback http://localhost:3000) under the installation context.
• apps/workers/workflow-workers/src/orchestrators/autoResolveIssue.ts
  • Passes jobId into shared usecase so initializeWorkflowRun uses that as the workflow run id.
  • Adds helpers to find/update a single status comment via a hidden marker and to render the comment body based on status.
  • Upserts the comment to "running" before kicking off the workflow, then to "completed" or "failed" after execution.

Why this approach

• Keeps the webhook handler small and focused: enqueue the job and post an initial comment immediately so users get fast feedback.
• Centralizes ongoing updates in the worker where workflow state is known, avoiding duplicate logic and additional server processes/subscribers.
• Uses an explicit marker to ensure we update the same comment without needing additional storage.

Notes

• ESLint passes (next lint). Prettier check is noisy for many pre-existing files in the repo and was not modified.
• No-breaking changes to existing workflows. The new behavior is additive and only activates for the "I2PR: Resolve Issue" label event.

Screens/UX

• The comment looks like:

  [Issue to PR] Workflow queued for auto-resolve

  Status: queued
  Details: https://your-app/workflow-runs/{jobId}

  This same comment is updated to "running", then to "completed" or "failed" with an error message if one occurs.

Closes #1322

[coderabbitai]

Important

Review skipped

Bot user detected.

To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[youngchingjui]

We should not be using the jobId for the workflow id. They are separate things. I'm not sure how bullmq creates the jobId.

It makes me think we should be standardizing ids across entities. Job id, workflow id, agent id, etc.

[youngchingjui]

I'm thinking the handlers might not be the right pattern now. Instead of our webhook listener "launching" a workflow or enqueing a job, perhaps we need to remap the webhook into our own event bus. But maybe that's also a lot of extra complication.

Because now we're giving the handlers multiple jobs. Including the updating the GitHub issue comment with latest updates.

Now that I've said that, perhaps we need to "listen" to the job status updates and make updates to the GitHub issue from there. So perhaps we need to attach a listener instead, with the GitHub issue link and the comment id.

[youngchingjui]

Probably don't need the hidden marker if we just have the comment id directly.