Skip to content
Critique/docs
Architecture

Event-Driven Pipeline

How Critique accepts GitHub events, deduplicates work, and runs reviews asynchronously.

Critique’s GitHub integration is event-driven: the HTTP handler that receives a webhook returns quickly; durable work runs in background workers so traffic spikes do not cause timeouts or dropped deliveries.

Webhook ingestion

When GitHub sends an event:

  1. Critique verifies the payload signature.
  2. A delivery record is stored with a unique delivery id (GitHub’s X-GitHub-Delivery header) so retries do not double-run the same work.
  3. Processing is queued and GitHub receives an immediate success response.

You can think of deliveries as an audit log: received → processing → completed, failed, ignored, or deduplicated.

What happens next

A delivery worker interprets the event type:

Event familyTypical outcome
Pull requestQueue or update a review run
Check run rerequestedMay re-queue review when it matches Critique’s check
Push (default branch)May refresh repository index / embeddings
Installation changesSync repos; may enqueue indexing for new repositories
PR / review commentsBot mentions, commands, optional PR comment chat

Not every webhook invokes models — many update bookkeeping only.

Review processing

PR reviews are often multi-step:

  1. Gather evidence — diff, files, guidance docs, sandbox collectors when enabled.
  2. Run specialists and synthesis — parallel lanes, then verdict.
  3. Publish to GitHub — check run, summary, inline comments.

Long sandbox work is split so analysis can retry independently from final publication. See PR review for the user-visible story.

Other queued work

The same infrastructure also drives Remedy, builder jobs, chat runs, and repository indexing. Each job type has its own handler but shares signature verification, retries, and delivery records.

Reliability

  • Idempotency — Duplicate GitHub deliveries are detected and skipped when safe.
  • Retries — Transient failures can be retried by the queue; operators may replay stuck deliveries from internal tools.
  • Lazy sync — Installation metadata is refreshed on hot paths so occasional missed webhooks do not strand repos permanently.

This page is an operator overview. Exact route names, queue products, and schema fields are internal implementation details subject to change.