✨ feat: propagate canonical request IDs through capture

[yeazelm]

Summary

• Preserve canonical request IDs through consolidated ext-proc capture and distinguish missing-header fallbacks.
• Install early Tapes API middleware that validates or generates the request ID and exposes it on the response and request context.
• Carry bounded request_id and provider upstream_request_id metadata independently across asynchronous ingest and worker execution.
• Keep both identifiers out of Prometheus labels and Loki stream labels.

How it works

The API establishes request-scoped correlation before handlers run. Ingest copies the Paper and provider identifiers into bounded job metadata, and workers restore both fields into their context and structured logger without allowing the provider ID to replace the Paper ID.

Test plan

• Contract fixture parity
• Full consolidated ext-proc suite
• Ext-proc image build
• Full E2E suite
• Cross-platform binary build
• Focused API, logger, ingest, and worker correlation suites

Fixes PCC-1177

[linear-code]

PCC-1177

[greptile-apps]

Greptile Summary

The PR adds request-correlation middleware to the API and propagates distinct Paper and provider request IDs through ingest and asynchronous worker execution.

• Validates or generates API request IDs and adds them to response headers, contexts, and structured logs.
• Copies bounded correlation metadata into worker jobs and restores it for storage calls and worker diagnostics.
• Persists both identifiers as raw-turn metadata while excluding them from metric labels.

Confidence Score: 4/5

The request-ID validation should be corrected before merging because parseable non-v4 UUIDs are currently returned as canonical identifiers.

The new middleware promises and tests for canonical UUIDv4 request IDs, but its implementation preserves any representation or UUID version accepted by uuid.Parse.

Files Needing Attention: api/request_id_middleware.go

Important Files Changed

Filename	Overview
api/request_id_middleware.go	Adds outermost request-ID middleware, but permissive UUID parsing does not enforce its asserted canonical UUIDv4 contract.
ingest/ingest.go	Separately bounds Paper and provider identifiers before carrying them into asynchronous worker metadata.
pkg/logger/request.go	Adds context accessors and structured logger construction that keep canonical and provider-issued IDs distinct.
proxy/worker/pool.go	Restores correlation metadata in worker contexts and includes it in worker logs and raw-turn metadata.

Sequence Diagram

sequenceDiagram
  participant Client
  participant API
  participant ExtProc
  participant Ingest
  participant Worker
  participant Storage
  Client->>API: Request with optional X-Request-Id
  API->>API: Validate or generate request_id
  API-->>Client: X-Request-Id
  ExtProc->>Ingest: Turn with request_id and upstream_request_id
  Ingest->>Ingest: Bound worker correlation fields
  Ingest->>Worker: Enqueue job metadata
  Worker->>Worker: Restore context and scoped logger
  Worker->>Storage: Correlated storage operations

Loading

Prompt To Fix All With AI

### Issue 1
api/request_id_middleware.go:32-39
**Noncanonical UUIDs pass validation**

When a caller supplies a parseable UUID that is not a canonical hyphenated UUIDv4, `canonicalRequestID` preserves it in the response header, request context, and logs, causing downstream correlation to receive an identifier outside the middleware's asserted UUIDv4 format.

```suggestion
func canonicalRequestID(candidate string) string {
	if len(candidate) <= maxRequestIDTextBytes {
		if parsed, err := uuid.Parse(candidate); err == nil &&
			parsed.Version() == uuid.Version(4) && parsed.String() == candidate {
			return candidate
		}
	}
	return uuid.NewString()
}
```

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

_{Reviews (1): Last reviewed commit: "✨ feat(ingest): preserve request IDs acr..." | Re-trigger Greptile}

[greptile-apps]

Noncanonical UUIDs pass validation

When a caller supplies a parseable UUID that is not a canonical hyphenated UUIDv4, canonicalRequestID preserves it in the response header, request context, and logs, causing downstream correlation to receive an identifier outside the middleware's asserted UUIDv4 format.

Suggested change

	func canonicalRequestID(candidate string) string {
	if len(candidate) <= maxRequestIDTextBytes {
	if _, err := uuid.Parse(candidate); err == nil {
	return candidate
	}
	}
	return uuid.NewString()
	}
	func canonicalRequestID(candidate string) string {
	if len(candidate) <= maxRequestIDTextBytes {
	if parsed, err := uuid.Parse(candidate); err == nil &&
	parsed.Version() == uuid.Version(4) && parsed.String() == candidate {
	return candidate
	}
	}
	return uuid.NewString()
	}

Knowledge Base Used: API server (api/)

Prompt To Fix With AI

This is a comment left during a code review.
Path: api/request_id_middleware.go
Line: 32-39

Comment:
**Noncanonical UUIDs pass validation**

When a caller supplies a parseable UUID that is not a canonical hyphenated UUIDv4, `canonicalRequestID` preserves it in the response header, request context, and logs, causing downstream correlation to receive an identifier outside the middleware's asserted UUIDv4 format.

```suggestion
func canonicalRequestID(candidate string) string {
	if len(candidate) <= maxRequestIDTextBytes {
		if parsed, err := uuid.Parse(candidate); err == nil &&
			parsed.Version() == uuid.Version(4) && parsed.String() == candidate {
			return candidate
		}
	}
	return uuid.NewString()
}
```

**Knowledge Base Used:** [API server (api/)](https://app.greptile.com/paper-compute/-/custom-context/knowledge-base/papercomputeco/tapes/-/docs/api-server.md)

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

[cloudflare-workers-and-pages]

Deploying docs-tapes-dev with    Cloudflare Pages

Latest commit:	d1f525e
Status:	🚫  Build failed.

View logs