# PR#36: the result comment holds the findings until the line comments exist

> **WARNING:** This document describes only the change applied in this PR.
> It may already be outdated once the next PR is merged.
> Historic PR documentation is not maintained along with new PRs; treat it as a snapshot.

## The Problem

Since PR#20, werkrevisor posts the result comment before the bot review with the line comments,
and the comment lists a finding with a line comment only by its title, "as a line comment".
If Gitea then refuses or fails the review, werkrevisor edits the comment to hold the full text.
If that edit fails too, the findings are only in the Werkator log, and only with their titles.
A rerun of the same head reuses the verdict without a model call and cannot bring them back.

Also from PR#20: no test shows the kind of the bot review for `yellow_gate = "block"` and `"pass_with_review_request"`.

## Non-Goals

- No change of the order of result comment and bot review: no approval stands without its comment.
- No change for reused line comments: their text is in the earlier line comment.

## The Scenarios

### Feature: no finding is lost when Gitea fails

#### Scenario#36.01: the result comment keeps the full findings if Gitea fails twice

So that the author can read every finding of the review.

- **Given** a review with a finding at a line of a changed file
- **When** Gitea fails the bot review with the line comment
  - **and** Gitea fails every edit of the result comment
- **Then** the result comment holds the full text of the finding

##### Verified by

- [test_line_comments: test_the_result_comment_keeps_the_findings_if_gitea_fails_twice](../../tests/test_line_comments.py)

#### Scenario#36.02: the result comment names the line comments once they exist

So that the full text of a finding is in one place only.

- **Given** a review with a finding at a line of a changed file
- **When** Gitea accepts the bot review with the line comment
- **Then** the result comment lists the finding by its title, "as a line comment"

##### Verified by

- [test_line_comments: test_finding_with_a_line_becomes_a_line_comment](../../tests/test_line_comments.py)
- [test_hints_hold_merge: test_a_later_edit_shortens_the_result_once_the_line_comments_exist](../../tests/test_hints_hold_merge.py)

### Feature: the kind of the bot review follows the gate

#### Scenario#36.03: without the approval gate, line comments come as COMMENT review

So that a repository without the approval gate still gets its line comments, but never an approval.

- **Given** `[gate] yellow_gate = "<gate>"`
- **When** werkrevisor reviews a PR with `<findings>` and the verdict `<verdict>`
- **Then** the bot submits `<review>`

| gate | findings | verdict | review |
|---|---|---|---|
| block | a finding at a line | GREEN | a COMMENT review |
| block | a finding at a line | ORANGE | a COMMENT review |
| block | no finding | GREEN | no review |
| pass_with_review_request | a finding at a line | GREEN | a COMMENT review |
| pass_with_review_request | no finding | GREEN | no review |

##### Verified by

- [test_line_comments: test_without_the_approval_gate_line_comments_come_as_comment_review](../../tests/test_line_comments.py)

## The Solution

- werkrevisor posts the result comment with the full text of every finding,
  and shortens it to the titles once Gitea has accepted the bot review with the line comments.
- A failed shortening leaves the full text, which repeats the line comments but loses nothing;
  a later edit of the same run, e.g. the note of a held merge, shortens it, since the line comments exist then.
  Otherwise the repetition stays: a rerun of the same head reuses the result comment as it is.
- werkrevisor 0.20.5.

## Additional Changes

- The fake Gitea of the tests gives a new comment the next free id, not the count of comments plus one,
  which could equal the id of an existing comment.

## Prerequisite PRs

- PR#35: Gradle build files reach the model.