Make upload analytics non-fatal in /api/upload and add tagged structured error logs

[Copilot]

📌 Purpose

Prevent PostHog failures from converting successful uploads into 500 responses in src/app/api/upload/route.ts, while preserving existing upload behavior and response shape.

---

🖼️ Showcase

Terminal/API behavior intent:

• Upload succeeds → returns existing 201 response even if analytics fails.
• Analytics failure is logged with [UPLOAD_ANALYTICS_ERROR].
• Real route failures are logged with [UPLOAD_ROUTE_ERROR] and still return generic upload 500.

---

🔧 Changes

• Separated failure domains

  • Wrapped only PostHog capture/flush in an inner try/catch after uploadPaper(...) succeeds.
  • Analytics exceptions are swallowed after logging (no rethrow), so upload success path is unaffected.

• Structured tagged logging

  • Added [UPLOAD_ANALYTICS_ERROR] log payload with name, message, stack.
  • Added [UPLOAD_ROUTE_ERROR] structured log in the outer catch with the same Error/non-Error normalization.

• No behavioral drift in upload contract

  • Kept existing success payload/status and existing generic route failure response.

try {
  const posthog = getPostHogClient();
  if (posthog) {
    posthog.capture({ /* ... */ });
    await posthog.flush();
  }
} catch (analyticsError) {
  console.error("[UPLOAD_ANALYTICS_ERROR]", {
    name: analyticsError instanceof Error ? analyticsError.name : "UnknownError",
    message: analyticsError instanceof Error ? analyticsError.message : String(analyticsError),
    stack: analyticsError instanceof Error ? analyticsError.stack : undefined,
  });
}

---

➕ Additional Notes

• Scope is intentionally surgical: only src/app/api/upload/route.ts changed.
• Relevant validation was run per issue requirement and passed.

[abhitrueprogrammer]

@copilot shouldn't the posthog init be in a seperate function (or not?) and should this be changed in both the routes that use server actions (src/app/api/request/route.ts)

[Copilot]

@copilot shouldn't the posthog init be in a seperate function (or not?) and should this be changed in both the routes that use server actions (src/app/api/request/route.ts)

getPostHogClient() is already the separate PostHog init function, so I kept that as-is. I’ve now applied the same non-fatal analytics pattern to src/app/api/request/route.ts as well (inner analytics try/catch + structured route/analytics error logs) in commit 8b14fea.

[abhitrueprogrammer]

lgtm