Add webhook receiver, ingestion workers, and server wiring

[Sauhard74]

Summary

Webhook Receiver (POST /api/webhooks/github)

• HMAC-SHA256 signature validation with timing-safe comparison
• Event-to-queue routing: pull_request, pull_request_review, issue_comment → PR ingestion; issues → issue ingestion; installation.created → batch sync
• Returns 202 with job ID on success, 200 for unhandled events

Ingestion Workers

Worker	Concurrency	Behavior
PR Ingestion	5	Upserts repo + PR, fetches file list and diff stats via GitHub API, resets analyzedAt on updates
Issue Ingestion	5	Upserts repo + issue, extracts labels, skips PRs received as issue events
Batch Sync	1	On new installation: paginates all repos, enqueues all open PRs + issues for individual processing with progress tracking

Server Setup

• Fastify with CORS + raw body parsing for webhook signature verification
• Health check endpoint (GET /health)
• Worker lifecycle: auto-start on boot, graceful stop on shutdown
• Shutdown sequence: stop workers → close queues → close Redis → close server
• SIGTERM + SIGINT signal handling

TRD Phase 1 Deliverables

• GitHub App scaffold with webhook receiver (Fastify, signature validation)
• PR/Issue ingestion pipeline with batch sync worker

Test plan

• Send test webhook with valid/invalid signatures, verify 202/401
• Verify PR ingestion upserts both repository and pull request records
• Verify issue ingestion skips events for pull requests
• Test batch sync enqueues all open PRs + issues for a mock installation
• Verify graceful shutdown cleans up all resources
• Confirm health endpoint returns { status: "ok" }

[Copilot]

Pull request overview

This PR implements the Phase 1 infrastructure for the PReview GitHub App, establishing webhook ingestion, job queue processing, and server lifecycle management. It provides the foundation for ingesting pull requests and issues from GitHub, with proper signature verification, event routing, and batch synchronization capabilities.

Changes:

• Added webhook receiver with HMAC-SHA256 signature verification and event-to-queue routing
• Implemented three BullMQ workers: PR ingestion (with GitHub API file fetching), issue ingestion (with PR filtering), and batch sync (with pagination for new installations)
• Set up Fastify server with CORS, raw body parsing, health endpoint, worker lifecycle management, and graceful shutdown handling

Reviewed changes

Copilot reviewed 9 out of 11 changed files in this pull request and generated 18 comments.

Show a summary per file

File	Description
pnpm-lock.yaml	Added dependencies for @octokit/auth-app, fastify-raw-body, and tsx, plus their transitive dependencies
packages/api/package.json	Updated dependencies to include @octokit/auth-app, fastify-raw-body, and @octokit/webhooks; added tsx as devDependency
packages/api/src/routes/webhooks.ts	Webhook receiver endpoint with signature validation, event routing, and job enqueueing
packages/api/src/routes/health.ts	Simple health check endpoint returning service status
packages/api/src/workers/pr-ingestion.worker.ts	PR ingestion worker that upserts repos/PRs and fetches file lists from GitHub API
packages/api/src/workers/issue-ingestion.worker.ts	Issue ingestion worker that upserts repos/issues and filters out PRs
packages/api/src/workers/batch-sync.worker.ts	Batch sync worker that paginates all repos/PRs/issues for new installations
packages/api/src/workers/index.ts	Worker lifecycle management with startup, event handling, and shutdown
packages/api/src/server.ts	Fastify server setup with plugins, routes, workers, and graceful shutdown handlers
packages/dashboard/tsconfig.json	Formatting changes and Next.js-specific configuration additions
packages/dashboard/next-env.d.ts	Auto-generated Next.js TypeScript definitions file

Files not reviewed (1)

• pnpm-lock.yaml: Language not supported

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Missing validation for empty repository full_name. If ghRepo.full_name doesn't contain a slash or is malformed, the split will result in an array without the expected structure, potentially causing issues with the GitHub API calls. Consider validating the format or using a more robust parsing approach with error handling.

Suggested change

	const [owner = "", repoName = ""] = ghRepo.full_name.split("/");
	const fullName = ghRepo.full_name?.trim();
	if (!fullName || !fullName.includes("/")) {
	job.log(`Invalid repository full_name format: "${ghRepo.full_name}"`);
	return;
	}
	const [owner, repoName] = fullName.split("/", 2);

[Sauhard74]

The webhook payload is signed and verified with HMAC-SHA256 before reaching this code — the data is trusted from GitHub. GitHub always provides full_name in owner/repo format; this field has a well-defined schema.

If it were somehow malformed, the subsequent GitHub API call would fail with a 404 and the job would retry (3 attempts with exponential backoff). The current defaults (owner = "", repoName = "") provide an implicit safety net. Adding explicit validation for every field GitHub sends would be excessive defensive coding at an internal boundary.

[Copilot]

The labels array contains either string or object with name property, but the extractLabels function assumes all elements conform to this. Consider adding runtime validation to handle unexpected label formats gracefully, as webhook payloads can vary or be modified by GitHub over time.

Suggested change

	return labels.map((l) => (typeof l === "string" ? l : l.name));
	if (!Array.isArray(labels)) {
	return [];
	}
	return labels
	.map((l) => {
	if (typeof l === "string") {
	return l;
	}
	if (l && typeof l === "object" && typeof (l as { name?: unknown }).name === "string") {
	return (l as { name: string }).name;
	}
	return null;
	})
	.filter((label): label is string => typeof label === "string");

[Sauhard74]

The TypeScript type already correctly models GitHub's API response — labels are either {name: string} objects or strings. The function handles both cases. Adding null-checking and filtering for formats GitHub doesn't produce adds complexity at an internal boundary where the data source is trusted (signed webhook payload from GitHub).

[Copilot]

The CORS origin is set to process.env["CORS_ORIGIN"] ?? true. When true, CORS allows all origins which could be a security risk in production. Consider defaulting to a more restrictive value or at least documenting that CORS_ORIGIN should be explicitly configured in production environments.

Suggested change

	await server.register(cors, {
	origin: process.env["CORS_ORIGIN"] ?? true,
	const corsOrigin = process.env["CORS_ORIGIN"];
	await server.register(cors, {
	origin: corsOrigin !== undefined ? corsOrigin : false,

[Sauhard74]

The CORS origin is controlled via the CORS_ORIGIN env var — set it to the dashboard URL in production. The true default is intentional for local development where the dashboard runs on a different port.

The webhook endpoint (POST /api/webhooks/github) is server-to-server (GitHub → our API) and isn't affected by CORS at all — browsers don't make these requests. CORS only matters for the dashboard's browser-based API calls, and permissive defaults in dev are the standard Fastify pattern.

[Copilot]

The worker event handlers use console.log and console.error directly instead of using the Fastify logger or a consistent logging strategy. Since the server has a configured logger, consider passing a logger instance to the workers or using a centralized logging utility for consistency across the application.

[Sauhard74]

BullMQ workers run outside the Fastify request lifecycle — they don't have access to the Fastify logger instance. console.log/console.error is the standard pattern for BullMQ worker event handlers. Introducing a shared logger abstraction is a valid Phase 2+ improvement but would be premature at this point.

[Copilot]

The deliveryId header is used without validation that it's a string. If the header is missing or is an array, it will be assigned as undefined or an array. Consider adding validation to ensure deliveryId is a string, or handle the undefined case explicitly in the job data.

[Sauhard74]

GitHub always sends the x-github-delivery header with every webhook. Even if it were undefined, deliveryId is only used as metadata in the job payload for tracing/debugging — it's not used for any logic, routing, or uniqueness constraints. No functional impact.

[Copilot]

The same issue exists here with ghRepo.full_name.split("/"): if the full_name is malformed or doesn't contain a slash, the destructuring will result in potentially empty strings for owner or repo. This could lead to invalid GitHub API calls throughout the batch sync process. Consider adding validation or error handling for malformed repository names.

Suggested change

	const [owner, repo] = ghRepo.full_name.split("/") as [string, string];
	const parts = ghRepo.full_name.split("/");
	if (parts.length !== 2 || !parts[0] || !parts[1]) {
	job.log(`Skipping repository with invalid full_name: "${ghRepo.full_name}"`);
	continue;
	}
	const [owner, repo] = parts as [string, string];

[Sauhard74]

Same reasoning as the PR ingestion worker — full_name comes from the GitHub API (fetched via GET /installation/repositories), not from user input. GitHub always returns it in owner/repo format.

[Copilot]

If an error occurs while processing one repository in the batch sync, the entire job will fail and potentially stop processing the remaining repositories. Consider wrapping the repository processing loop in error handling to log failures for individual repos while continuing to process others, ensuring more resilient batch syncs.

[Sauhard74]

Valid — one failing repo would abort the entire sync across all repositories. Wrapping the per-repo loop body in try-catch so failures are logged and skipped without blocking other repos.

[Copilot]

The payload is cast to Record<string, unknown> after signature verification, but request.body is used. This assumes that Fastify has already parsed the JSON body. While this works with the current setup, it's inconsistent with using rawBody for signature verification. Consider documenting this behavior or parsing the body explicitly from bodyString to ensure consistency.

Suggested change

	const payload = request.body as Record<string, unknown>;
	let payload: Record<string, unknown>;
	try {
	const parsed = JSON.parse(bodyString);
	if (!parsed || typeof parsed !== "object" || Array.isArray(parsed)) {
	return reply.code(400).send({ error: "Invalid JSON payload" });
	}
	payload = parsed as Record<string, unknown>;
	} catch {
	return reply.code(400).send({ error: "Invalid JSON payload" });
	}

[Sauhard74]

Using Fastify's auto-parsed `request.body` alongside `request.rawBody` for signature verification is the documented fastify-raw-body pattern. The plugin captures the raw body via a preParsing hook before Fastify parses the JSON.

• `rawBody`: unparsed string for HMAC signature verification
• `request.body`: parsed JSON for application logic

Manually parsing `bodyString` would be redundant since Fastify already did the work. This is the standard webhook verification approach in Fastify (same pattern used for Stripe, Slack, etc.).

[Copilot]

The shutdown handlers use void operator to suppress the returned promise, but this means errors during shutdown won't be caught or logged. Consider adding error handling to the shutdown function calls or using .catch() to log any shutdown errors for better debugging of graceful shutdown failures.

Suggested change

	process.on("SIGTERM", () => void shutdown());
	process.on("SIGINT", () => void shutdown());
	process.on("SIGTERM", () => {
	shutdown().catch((err) => {
	server.log.error({ err }, "Error during shutdown on SIGTERM");
	});
	});
	process.on("SIGINT", () => {
	shutdown().catch((err) => {
	server.log.error({ err }, "Error during shutdown on SIGINT");
	});
	});

[Sauhard74]

Agreed — void shutdown() swallows errors silently. Adding .catch() with error logging so shutdown failures are visible.

[Copilot]

The batch sync worker enqueues jobs for all open PRs and issues without any rate limiting or batching control. For installations with hundreds or thousands of open items, this could overwhelm Redis and the worker queues. Consider implementing batching with delays between batches, or using BullMQ's bulk add functionality with flow controls to manage the load more gracefully.

[Sauhard74]

Jobs are added one at a time with `await` (not `addBulk`), and the loop is naturally throttled by the GitHub API pagination response time between repos. Each `queue.add()` is a single Redis command.

The downstream workers have concurrency limits (5 for PR/issue ingestion, 1 for batch sync), so jobs are processed at whatever rate the workers can sustain — BullMQ handles backpressure natively. Redis can handle thousands of queue entries without issue.

For Phase 2+ optimization on very large repos (5000+ PRs), we may consider chunked `addBulk` for throughput, but the current serial approach is correct for Phase 1.

[iyad-f]

@Sauhard74 just make sure PR's focus on a single aspect and doesn't manage to have scope creep