feat: add logging for trials

[mfts]

Summary by CodeRabbit

• Chores
  • Added a new logging utility that conditionally outputs events to console during development or sends them to a remote endpoint in production. Now integrated with dataroom trial event tracking and includes automatic error handling.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Comments	Updated (UTC)
papermark	Ready	Preview	Comment	Dec 8, 2025 6:02pm

[coderabbitai]

Walkthrough

A new logStore utility function is added to handle conditional logging of events. It logs to console during development or when a webhook URL is absent, otherwise POSTs data to a remote webhook. The trial dataroom endpoint is updated to use this function for persisting trial event data.

Changes

Cohort / File(s)	Summary
New logging utility lib/utils.ts	Added exported async function logStore that conditionally logs to console (development mode or missing webhook URL) or POSTs event data to a remote webhook with error handling.
Trial event logging integration pages/api/teams/[teamId]/datarooms/trial.ts	Imported and integrated logStore to persist trial event data including teamId, email, fullName, companyName, useCase, companySize, and tools; no public API changes.

Pre-merge checks

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'feat: add logging for trials' directly corresponds to the main change: introducing logStore functionality for structured logging of dataroom trial events.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (2)

lib/utils.ts (1)

64-88: logStore implementation is functionally sound; consider tightening the API surface

The control flow looks correct and safe for a logging helper: it short‑circuits to console logging in dev / when the webhook URL is absent, and otherwise best‑effort POSTs and logs failures without throwing. This is consistent with how log behaves.

A couple of small API/typing cleanups you might consider (non‑blocking):

• The current return type ends up as Promise<void | Response | undefined>, but callers (e.g. the trial handler) don’t use the Response. You could simplify by not returning the network call result and just await it, making this a pure side‑effect helper with an implicit Promise<void> return:

  try {
    if (process.env.PPMK_STORE_WEBHOOK_URL) {
      await fetch(process.env.PPMK_STORE_WEBHOOK_URL, {
        method: "POST",
        headers: { "Content-Type": "application/json" },
        body: JSON.stringify(object),
      });
    }
  } catch (e) {
    console.error("Error logging store:", e);
  }

• The parameter shape ({ object }: { object: any }) forces a slightly awkward call‑site. If you don’t need that extra nesting, you could make the helper generic and accept any serializable payload directly:

  export const logStore = async <T>(payload: T) => { /* ... JSON.stringify(payload) ... */ };

  and call it as await logStore({ teamId, email, fullName, ... }).

These changes would make the helper easier to re‑use and reason about without altering behavior for existing call sites that just await it.

pages/api/teams/[teamId]/datarooms/trial.ts (1)

16-16: Structured trial logging via logStore looks good; consider making it non‑blocking

Importing logStore and pushing a structured payload (teamId, email, fullName, companyName, useCase, companySize, tools) is a nice complement to the existing Slack log and should make downstream analysis much easier.

One thing to consider: both log and logStore are awaited on the request path. Since logStore has built-in error handling (catches and logs errors internally), you could reduce latency and coupling by not blocking on it:

• Fire‑and‑forget:

  logStore({
    object: { teamId, email, fullName, companyName, useCase, companySize, tools },
  });

  (or void logStore(...); if your lint rules require explicit acknowledgement)

• Or, if you already have a background task mechanism, run the store logging there alongside the scheduled emails so a slow/unavailable store can't delay the API response.

Also, this payload includes several user identifiers (email, fullName, company/companySize). Make sure the target behind PPMK_STORE_WEBHOOK_URL is treated as a trusted, compliant destination for that PII and is covered by your data‑retention policies.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 01c7812 and 4bbaf70.

📒 Files selected for processing (2)

• lib/utils.ts (1 hunks)
• pages/api/teams/[teamId]/datarooms/trial.ts (2 hunks)

🧰 Additional context used

🧬 Code graph analysis (1)

pages/api/teams/[teamId]/datarooms/trial.ts (1)

lib/utils.ts (1)

• logStore (64-88)