Skip to content

feat(review): persist review id + correct ADR-0035 capture (poll, not webhook) — #144 part 1#161

Merged
stephane-segning merged 1 commit into
mainfrom
claude/144-feedback-foundation
Jun 22, 2026
Merged

feat(review): persist review id + correct ADR-0035 capture (poll, not webhook) — #144 part 1#161
stephane-segning merged 1 commit into
mainfrom
claude/144-feedback-foundation

Conversation

@stephane-segning

Copy link
Copy Markdown
Contributor

1. Summary

The unblocking prerequisite for #144 / ADR-0035 (review feedback 👍/👎), plus a verified correction to the ADR's capture mechanism.

  • Persist the GitHub review id at write-back so a later feedback signal can correlate back to the run: create_pr_review now returns PostedReview { id, html_url }; migration 0013 adds reviews.github_review_id; upsert_review/ReviewRow/finalize thread it.
  • Corrected ADR-0035: I verified against GitHub's webhook-events docs that GitHub does not emit reaction webhooks (no reaction event; issue_comment/pull_request_review_comment fire on create/edit/delete, never on a reaction). The ADR's "subscribe to reaction events" is infeasible — capture must poll the reactions REST API and reconcile (which yields the un-react/"deleted" case for free). Also noted: per-comment ids aren't in the create-review response; they need a follow-up GET at capture time.

Source of truth: #144 / ADR-0035.


2. Intent

ADR-0035 itself says persist the IDs first, "even before the feature ships" — it's cheap, independently useful, and unblocks any capture path. And rather than build a handler for a webhook GitHub never sends, I verified the premise and corrected the ADR to the real mechanism (polling) before writing capture code.


3. Scope

In Scope

  • Persist github_review_id; ADR-0035 correction (webhook → poll).

Out of Scope (the corrected part 2 — follow-up)

  • The polling job (fetch reactions for owned comment ids + reconcile), the review_feedback table, per-comment id capture (follow-up GET), and the dashboard surface. These need a poller (control-plane background loop or the ADR-0028 jobs sidecar) + apps/web work — flagged for direction.

4. Verification

  • Running automated tests
  • Verified the reaction-webhook premise against GitHub docs (it's false → ADR corrected)
DATABASE_URL=postgres://lightbridge:lightbridge@localhost:5432/lightbridge cargo test -p control-plane --locked
cargo fmt --check && cargo clippy -p control-plane --all-targets
control-plane: 57 passed (review-persist test now asserts github_review_id); fmt + clippy clean

5. Screenshots / Evidence

ADR-0035 amended in this PR with the verified correction (status line + Decision Outcome part 2).


6. Risk Assessment

  • Low — additive nullable column; the create-review response already carries the id; no behaviour change to posting.

7. AI Usage Declaration

AI was used for:

  • Understanding existing code
  • Generating code
  • Generating tests
  • Drafting documentation (ADR correction)
  • Reviewing the diff

Human verification:

  • I verified the GitHub reaction-webhook claim empirically (docs)
  • I understand every meaningful change
  • I accept responsibility for this PR

8. Reviewer Focus

  • Correctness (id persistence + migration)
  • The ADR-0035 correction (is the polling mechanism the right call?)

🤖 Generated with Claude Code

… mechanism (#144 part 1)

ADR-0035 part 1 (the stated prerequisite — "do this now even before the
feature ships"): on write-back, keep the GitHub review id we create so a
later 👍/👎 feedback signal can correlate back to the run.
- github.rs: create_pr_review returns PostedReview { id, html_url } (was
  just html_url); the create-review response carries the review object.
- migration 0013 + reviews.github_review_id; upsert_review + ReviewRow
  thread it; finalize stores it.

Also CORRECTS ADR-0035: verified against GitHub's webhook-events docs that
GitHub does NOT emit reaction webhooks (no `reaction` event; issue_comment/
pull_request_review_comment fire on create/edit/delete, never on a
reaction). So part 2's "subscribe to reaction events" is infeasible —
capture must POLL the reactions REST API and reconcile (which also yields
the un-react/"deleted" behaviour for free). Per-comment ids aren't in the
create-review response either; they need a follow-up GET at capture time.

control-plane 57 (pg17) green; fmt + clippy clean. The polling capture +
review_feedback table + dashboard is the follow-up (part 2).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@chatgpt-codex-connector

Copy link
Copy Markdown

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

@github-actions

Copy link
Copy Markdown

✅ AI Governance check passed

This PR declares AI usage, references a source of truth, and provides verification evidence. Thank you.

@gemini-code-assist gemini-code-assist Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request implements the first part of ADR-0035 by persisting the GitHub review ID when writing back reviews. It updates the ADR documentation to correct the feedback capture mechanism from webhooks to polling, adds a database migration to store github_review_id in the reviews table, and updates the database, HTTP internal handlers, and GitHub integration code to propagate and persist this ID. There are no review comments to address.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

@stephane-segning stephane-segning merged commit 876de38 into main Jun 22, 2026
7 checks passed
@stephane-segning stephane-segning deleted the claude/144-feedback-foundation branch June 22, 2026 20:36
stephane-segning added a commit that referenced this pull request Jun 22, 2026
…162)

* feat(observability): persist the agent run transcript — backend (#143, ADR-0034)

The runner records its run transcript (assistant reasoning + tool calls +
per-turn token usage, and bounded tool results) and submits it to the
control plane at run end — even on failure, so a failed run's reasoning is
inspectable. The control plane stores it and serves a read API for the
(future) dashboard timeline. UI deferred per scope.

- runner: chat Completion now carries token `usage`; run_native_agent fills
  a transcript Vec the caller owns + submits best-effort (client.submit_
  transcript); tool results truncated to 2 KiB.
- control-plane: migration 0014 agent_transcript; replace_transcript (txn:
  a retry re-submit fully replaces) + get_transcript; ingest endpoint
  POST /internal/tasks/{id}/transcript; read GET /tasks/{id}/transcript
  (gated review:read).

NOTE: migration numbered 0014 to sit after #144's 0013 — merge #161 first
so prod's migration sequence has no gap.

agent-runner 30 + control-plane 58 (pg17, incl. transcript test) green;
fmt + clippy clean.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

* fix(transcript): 404 on unknown task in ingest (Gemini #162)

Resolve the task before replace_transcript so an unknown id is a clean 404
instead of a foreign-key 500 on insert — mirrors ingest_chunks/ingest_graph.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant