# What Pull Request Events Trigger Updates to Asana Tasks and Subtasks?

> Discover which pull request events update Asana tasks and subtasks. Learn how synchronize, edited, labeled, review requested and other events trigger specific Asana updates.

- Repository: [Keita Kitamura/github-asana-request-review-action](https://github.com/keitap/github-asana-request-review-action)
- Tags: how-to-guide
- Published: 2026-03-05

---

**Pull request `synchronize`, `edited`, `labeled`, `unlabeled`, `review_requested`, and `review_request_removed` actions trigger updates to Asana reviewer subtasks, while all `pull_request` events update the parent task description, and every `pull_request_review` event updates the corresponding subtask comment.**

The `keitap/github-asana-request-review-action` GitHub Action listens to GitHub webhook payloads to keep Asana tasks synchronized with pull request activity. Understanding exactly which pull request events trigger updates to Asana tasks and subtasks helps teams troubleshoot automation gaps and ensure code review tracking remains accurate. The action distinguishes between general PR activity and specific reviewer-related changes through a guarded event handling system implemented in the core handler.

## Pull Request Events That Update Reviewer Subtasks

The action processes `pull_request` webhooks through the `updateReviewers` function in [`handler.go`](https://github.com/keitap/github-asana-request-review-action/blob/main/handler.go), but only six specific actions trigger the creation or modification of reviewer subtasks. These actions are defined as constants at the top of [`handler.go`](https://github.com/keitap/github-asana-request-review-action/blob/main/handler.go) and checked via the `shouldUpdateReviewerEvent` boolean guard.

The following pull request actions trigger reviewer subtask updates:

- **`synchronize`** – When new commits are pushed to the pull request branch.
- **`edited`** – When the pull request title or description is modified.
- **`labeled`** – When a label is added to the pull request.
- **`unlabeled`** – When a label is removed from the pull request.
- **`review_requested`** – When a reviewer is assigned to the pull request.
- **`review_request_removed`** – When a reviewer is unassigned from the pull request.

If the action does not match one of these six strings, `updateReviewers` returns early without modifying subtasks. This guard logic ensures that high-frequency events like `opened` or `closed` do not trigger unnecessary Asana API calls for reviewer management.

```go
// Example: A PR description is edited (action = "edited")
handler.Handle("pull_request", payload)
// → updateTask adds/updates the description comment on the parent Asana task
// → updateReviewers proceeds because shouldUpdateReviewerEvent is true
// → upsertReviewer creates or updates the reviewer subtask

```

## Parent Task Updates for All PR Events

While reviewer subtasks update conditionally, **every** `pull_request` webhook triggers an update to the parent Asana task. The `updateTask` function adds or updates a comment on the parent task containing the "review description" — a summary of the pull request state, links, and metadata.

This means events like `opened`, `closed`, or `reopened` still refresh the Asana task description comment even though they skip the reviewer subtask logic.

```go
// Example: A PR is opened (action = "opened")
handler.Handle("pull_request", payload)
// → updateTask runs (updates parent task description)
// → updateReviewers returns early (does not touch reviewer subtasks)

```

## Pull Request Review Events

Unlike the selective filtering applied to pull request actions, **all** `pull_request_review` events trigger updates to Asana subtasks. When GitHub sends a `pull_request_review` webhook — whether the review is created, edited, or dismissed — the `handlePullRequestReviewEvent` function executes unconditionally.

This handler:
1. Parses the Asana task link from the pull request body.
2. Resolves the reviewer's Asana account using the mapping in [`config.go`](https://github.com/keitap/github-asana-request-review-action/blob/main/config.go).
3. Locates the existing reviewer subtask by name.
4. Adds or updates a comment via `AddCodeReviewSubtaskComment` containing the review state, comment count, and direct link to the GitHub review.

```go
// Example: A reviewer submits a review
handler.Handle("pull_request_review", payload)
// → handlePullRequestReviewEvent parses the task ID and reviewer info
// → Finds the subtask by reviewer name
// → AddCodeReviewSubtaskComment adds the review state and link

```

## Core Implementation Details

The event filtering logic resides in [`handler.go`](https://github.com/keitap/github-asana-request-review-action/blob/main/handler.go), which serves as the webhook dispatcher for the action.

**Action Constants** – The six valid PR actions are defined as string constants at the top of [`handler.go`](https://github.com/keitap/github-asana-request-review-action/blob/main/handler.go) (e.g., `prEventActionSynchronize`, `prEventActionEdited`).

**Reviewer Guard Logic** – Inside `updateReviewers`, the code constructs the `shouldUpdateReviewerEvent` boolean by checking if the payload action matches any of the six allowed values. Only when this guard returns true does the function proceed to call `upsertReviewer`.

**Subtask Upsert Operations** – The `upsertReviewer` function either creates a new code-review subtask via `AddCodeReviewSubtask` or updates an existing one via `UpdateCodeReviewSubtask`. This operation only executes if the reviewer has a linked Asana account (`reviewer.AsanaUserGID` exists).

**Review Event Handling** – The `handlePullRequestReviewEvent` function does not implement action-based filtering. It processes the payload regardless of whether the review is new, modified, or dismissed, ensuring the subtask comment always reflects the latest review state.

## Summary

- **Six specific pull request actions** (`synchronize`, `edited`, `labeled`, `unlabeled`, `review_requested`, `review_request_removed`) trigger updates to reviewer subtasks via the `shouldUpdateReviewerEvent` guard in `updateReviewers`.
- **All `pull_request` events** update the parent Asana task description comment through `updateTask`, regardless of action type.
- **All `pull_request_review` events** trigger `handlePullRequestReviewEvent`, which updates the reviewer subtask comment without filtering on review state.
- The core logic resides in [`handler.go`](https://github.com/keitap/github-asana-request-review-action/blob/main/handler.go), with subtask operations implemented in [`asana.go`](https://github.com/keitap/github-asana-request-review-action/blob/main/asana.go) and user mappings defined in [`config.go`](https://github.com/keitap/github-asana-request-review-action/blob/main/config.go).

## Frequently Asked Questions

### Which pull request actions trigger updates to reviewer subtasks?

Only six actions trigger reviewer subtask updates: `synchronize` (new commits), `edited` (title/description changes), `labeled`/`unlabeled` (label changes), and `review_requested`/`review_request_removed` (reviewer assignment changes). These are explicitly checked in the `shouldUpdateReviewerEvent` guard within [`handler.go`](https://github.com/keitap/github-asana-request-review-action/blob/main/handler.go).

### Do all pull request events update the Asana task description?

Yes. Every `pull_request` webhook triggers `updateTask` to add or update the review description comment on the parent Asana task. This includes actions like `opened`, `closed`, and `reopened` that do not trigger reviewer subtask updates.

### What happens when a pull request review is submitted?

When any `pull_request_review` event occurs (created, edited, or dismissed), the `handlePullRequestReviewEvent` function finds the reviewer's subtask and adds a comment containing the review state, comment count, and direct link to the GitHub review. Unlike PR events, review events are not filtered by action type.

### Where is the logic that determines if a PR event should update reviewer subtasks?

The filtering logic resides in the `updateReviewers` function inside [`handler.go`](https://github.com/keitap/github-asana-request-review-action/blob/main/handler.go). This function builds a boolean `shouldUpdateReviewerEvent` that returns true only for the six specific action strings defined as constants at the top of the file.