fix: community reply crash due to missing envelope unwrapping

[seanhanca]

The community hub frontend API client was returning raw JSON responses without unwrapping the { success, data } envelope used by the Next.js proxy routes. This caused:

• createComment to return the wrapper object instead of the comment, so comment.content was undefined → crash in renderMarkdown
• Nested author shape from Prisma (author.user.displayName) not being flattened to the expected author.displayName format

Fixed by:

• Adding normalizeAuthor/normalizeComment helpers that handle both the Prisma nested shape and the flat formatProfile shape
• Unwrapping the { success, data } envelope in createComment, acceptAnswer, voteComment, votePost, removeVote, checkVoted, fetchComments, fetchPost, and updatePost
• Adding a null guard in renderMarkdown as a defensive measure

Summary

Changes

Type

• Feature
• Bug fix
• Refactor
• Documentation
• CI / Tooling
• Plugin (new or update)
• Dependencies

Plugin(s) Affected

Checklist

• Tests pass locally
• Lint passes (npm run lint)
• Build succeeds (npm run build)
• No new lint warnings introduced
• Breaking changes documented below
• Database migration included (if Prisma schema changed)

Breaking Changes

None

Screenshots / Recordings

Summary by CodeRabbit

• New Features

  • Added support for stop sequences in AI completion requests.

• Bug Fixes

  • Improved email service to properly handle recipient objects.
  • Enhanced null/undefined handling in markdown rendering.

• Chores

  • Upgraded testing framework to latest version.
  • Added interactive prompt library dependency.
  • Enhanced plugin creation workflow with improved defaults and type safety.

[vercel]

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

Project	Deployment	Actions	Updated (UTC)
naap-platform	Ready	Preview, Comment	Feb 10, 2026 7:12pm

[vercel]

Removed early return that bypassed normalization, which could return incomplete User objects missing required interface fields

[vercel]

normalizeComment function accesses required fields (id, postId, createdAt, updatedAt) without validation, risking undefined values in returned Comment objects if API response is malformed

[github-actions]

⚠️ This PR is very large (1704 lines changed). Please split it into smaller, focused PRs if possible.

[seanhanca]

@coderabbitai review

[coderabbitai]

✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

[coderabbitai]

📝 Walkthrough

Walkthrough

This pull request updates test infrastructure dependencies for the web-next package, enhances test reliability with explicit timer management, improves plugin SDK CLI command type safety and defaults, adds email configuration handling, updates service types with new options, and normalizes API response handling in the community frontend.

Changes

Cohort / File(s)	Summary
Test Infrastructure & Config apps/web-next/package.json, apps/web-next/vitest.config.ts	Major version upgrade of vitest and @vitest/coverage-v8 from ^2.1.0 to ^4.0.18; added coverage.reportsDirectory configuration.
Hook Tests apps/web-next/src/hooks/__tests__/useDashboardQuery.test.ts, apps/web-next/src/hooks/__tests__/useJobFeedStream.test.ts	Refactored retry error tests to use fake timers with multiple retry cycle advancement (5 × 5000ms) and persistent rejection mocking; timers reset after assertions.
Plugin Integration Tests apps/web-next/src/lib/plugins/__tests__/integration.test.ts	Updated token assertions to async checks with falsy expectations under strictMode; changed logger prefix format assertion; replaced static feature flag imports with dynamic async imports and reset after each test.
Plugin SDK CLI Commands packages/plugin-sdk/cli/commands/create.ts, packages/plugin-sdk/cli/commands/dev.ts, packages/plugin-sdk/cli/commands/github.ts, packages/plugin-sdk/cli/commands/package.ts	Added CreateAnswers interface with stricter typing; renamed plugin category from 'tool' to 'developer-tools'; introduced safe defaults for pluginName, template, and manifest fields; changed processes array type to any with eslint disable comment; added pluginType fallback to 'full-stack'; changed skipMfValidation to skipBundleValidation.
Plugin SDK CLI & Deps packages/plugin-sdk/cli/index.ts, packages/plugin-sdk/package.json	Changed buildCommand static export to createBuildCommand factory function; added @inquirer/prompts dependency.
Plugin SDK Email Integration packages/plugin-sdk/src/integrations/email/sendgrid.ts	Added private convertOptions helper to transform EmailOptions with recipient objects into flat string fields (from, replyTo, cc, bcc).
Plugin SDK Services & Utilities packages/plugin-sdk/src/types/services.ts, packages/plugin-sdk/src/utils/api.ts	Added optional stopSequences property (string | string[]) to AICompletionOptions; aliased getServiceOrigin import to \_getServiceOrigin.
Community Frontend API plugins/community/frontend/src/api/client.ts	Introduced normalizeAuthor and normalizeComment helpers to flatten nested author shapes; refactored all API response handlers to unwrap envelope structures and apply normalization; standardized return types for Post, Comment, and User entities.
Community Frontend Components plugins/community/frontend/src/pages/PostDetail.tsx	Updated renderMarkdown signature to accept string | undefined | null with early falsy guard for safe rendering.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Poem

🐰 With timers mocked and types made strong,
The SDK dances along,
Defaults flow, responses align,
Authors flatten, comments shine,
A plugin's path made clear and fine! ✨

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 29.41% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ 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 accurately captures the main fix: unwrapping the envelope in community API responses to prevent crashes, which is the primary change across the changeset.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch fix/community-reply-crash

---

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

[coderabbitai]

Actionable comments posted: 4

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

apps/web-next/package.json (1)

62-71: ⚠️ Potential issue | 🟠 Major

Vitest 4.x upgrade requires configuration and coverage migration.

This major version bump includes breaking changes that must be addressed:

• Config: maxThreads/maxForks → maxWorkers; remove singleThread/singleFork (use maxWorkers: 1 + isolate: false); move poolOptions to top-level test config; rename vmMemoryLimit
• Fake timers: Default behavior changed; if tests behave differently, explicitly pin fakeTimers.toFake (e.g., ['setTimeout', 'setInterval', 'Date'])
• Coverage: V8 remapping now AST-based; removed coverage.all, coverage.extensions, coverage.ignoreEmptyLines, and coverage.experimentalAstAwareRemapping; add coverage.include to specify source file patterns (coverage numbers will shift vs v3)

Update vitest.config.ts accordingly before proceeding.

🤖 Fix all issues with AI agents

In `@apps/web-next/src/hooks/__tests__/useDashboardQuery.test.ts`:
- Around line 76-96: Move vi.useFakeTimers() and vi.useRealTimers() out of the
individual test into test-scoped setup/teardown: add a beforeEach that calls
vi.useFakeTimers() and an afterEach that calls vi.runOnlyPendingTimers() then
vi.useRealTimers(); in the test "returns error with type=no-provider when no
handler registered" remove the vi.useFakeTimers()/vi.useRealTimers() calls and
keep the retry timer advances (vi.advanceTimersByTime) as-is so
mockEventBus.request rejection behavior is exercised; reference
mockEventBus.request and the test name to locate the block and ensure the new
beforeEach/afterEach surround all tests in useDashboardQuery.test.ts.

In `@apps/web-next/src/hooks/__tests__/useJobFeedStream.test.ts`:
- Around line 143-164: The test "returns error when no provider registered"
currently calls vi.useFakeTimers() and vi.useRealTimers() inline, which can leak
timers on failures; move the vi.useFakeTimers() call into the existing
beforeEach for this test suite and add an afterEach that calls
vi.clearAllTimers() and vi.useRealTimers() (or at minimum vi.useRealTimers()) so
fake timers are always restored; update references in the file
apps/web-next/src/hooks/__tests__/useJobFeedStream.test.ts and ensure the test
body (useJobFeedStream hook test) no longer toggles timers itself.

In `@packages/plugin-sdk/src/integrations/email/sendgrid.ts`:
- Around line 87-102: sendTemplate is constructing the SendGrid payload using
options?.from and options?.replyTo as EmailRecipient objects, which serializes
incorrectly; reuse the existing convertOptions(options) helper to normalize
EmailOptions into plain strings and merge its result into the payload before
sending. Update sendTemplate to call convertOptions(options) and use the
returned from/replyTo/cc/bcc values (instead of directly accessing
options?.from/options?.replyTo), ensuring the payload matches how send and
sendHtml build their requests.

In `@plugins/community/frontend/src/api/client.ts`:
- Around line 393-395: The acceptAnswer return path currently passes the raw
response into normalizeComment without handling the nested shape { data: {
comment } }; update the parsing in the acceptAnswer flow (same area where json
is parsed and normalizeComment is called) to unwrap json.data.comment first,
then fall back to json.data and finally json (e.g. use json.data?.comment ??
json.data ?? json) so normalizeComment receives the actual Comment object;
mirror the behavior used by createComment to ensure IDs are preserved.

🧹 Nitpick comments (3)

packages/plugin-sdk/cli/commands/dev.ts (1)

52-53: Consider using a more specific type instead of any.

Using any bypasses type safety for the spawned processes. Consider importing the proper type from execa or using a minimal interface:

♻️ Proposed fix using a minimal interface

-    // eslint-disable-next-line `@typescript-eslint/no-explicit-any`
-    const processes: { name: string; process: any }[] = [];
+    import type { ResultPromise } from 'execa';
+    // ...
+    const processes: { name: string; process: ResultPromise<{ reject: false }> }[] = [];

Alternatively, if the execa types are problematic, define a minimal interface for what's actually used:

interface SpawnedProcess {
  stdout: NodeJS.ReadableStream | null;
  stderr: NodeJS.ReadableStream | null;
  kill: () => void;
}
const processes: { name: string; process: SpawnedProcess }[] = [];

packages/plugin-sdk/package.json (1)

66-66: Consolidate prompt libraries by migrating create.ts to @inquirer/prompts.

Both @inquirer/prompts and the legacy inquirer package are currently in use: create.ts imports from inquirer while github.ts imports from @inquirer/prompts. Since @inquirer/prompts is the modern, tree-shakeable successor with better TypeScript support, migrate the prompts in create.ts to use @inquirer/prompts and remove the inquirer dependency and its @types/inquirer devDependency to reduce bundle size and dependency count.

plugins/community/frontend/src/api/client.ts (1)

276-277: Normalize author in update responses for consistency.
If the proxy returns the Prisma nested author shape here, callers still receive an unflattened author. Consider applying normalizeAuthor (and optionally comment normalization if present) like fetchPost.

♻️ Suggested change

-  const json = await res.json();
-  return json.data?.post ?? json.data ?? json;
+  const json = await res.json();
+  const raw = json.data?.post ?? json.data ?? json;
+  if (raw?.author) raw.author = normalizeAuthor(raw.author);
+  return raw;

[coderabbitai]

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🌐 Web query:

Vitest useFakeTimers useRealTimers cleanup best practices

💡 Result:

Best practices for vi.useFakeTimers() / vi.useRealTimers() (Vitest)

1) Don’t let fake timers leak across tests

Set them up in beforeEach and always restore in afterEach. vi.useFakeTimers() affects timers and Date until you switch back. vi.useRealTimers() returns native timers and discards timers that were scheduled while fake timers were enabled. [2]

import { beforeEach, afterEach, vi } from 'vitest'

beforeEach(() => {
  vi.useFakeTimers()
})

afterEach(() => {
  // flush anything your test (or libs) scheduled
  vi.runOnlyPendingTimers() // or vi.runAllTimers() if appropriate
  vi.useRealTimers()

  vi.restoreAllMocks()
})

Vitest’s own timer guide shows the same general pattern (fake timers in beforeEach, cleanup in afterEach). [3]

2) Flush pending timers before switching back to real timers

When using fake timers, it’s easy for libraries to schedule work you didn’t notice. Testing Library explicitly recommends running pending timers (e.g. runOnlyPendingTimers) before restoring real timers to avoid “scheduled tasks never executed” surprises. [1]

3) If you use Testing Library, ensure DOM cleanup is actually happening

React Testing Library’s cleanup runs automatically only if the test framework provides a global afterEach. For Vitest, that typically means enabling test.globals: true; otherwise, add a setup file that calls cleanup() in afterEach. [4]

4) Be careful mixing fake timers with user-event / waitFor

There are known cases where @testing-library/user-event interactions can hang/time out under fake timers in Vitest (and similar issues around async utilities). If you hit this, prefer real timers for those tests, or use the library’s recommended timer-advancing integration patterns. [1], [6]

5) Only fake what you need (advanced)

Vitest uses @sinonjs/fake-timers and lets you control what gets faked (e.g. opting into nextTick / queueMicrotask), plus global defaults like clearing native timers. Use this sparingly—faking more APIs increases the chance of subtle hangs. [2], [5]

Sources: Testing Library fake timers guidance [1]; Vitest vi.useFakeTimers / vi.useRealTimers API [2]; Vitest timers guide [3]; React Testing Library Vitest auto-cleanup setup [4]; Vitest fake-timers config [5]; Vitest issue showing userEvent + fake timers timeout symptom [6].

---

🏁 Script executed:

head -120 apps/web-next/src/hooks/__tests__/useDashboardQuery.test.ts

Repository: livepeer/naap

Length of output: 3707

---

Use beforeEach/afterEach hooks instead of try/finally to manage fake timers.

Vitest's recommended pattern is to set up vi.useFakeTimers() in beforeEach and restore in afterEach, not in individual test blocks. Additionally, flush pending timers with vi.runOnlyPendingTimers() before calling vi.useRealTimers() to ensure no scheduled tasks are discarded:

🛠️ Suggested fix

 describe('useDashboardQuery', () => {
   const testQuery = '{ kpi { successRate { value delta } } }';
   const testData = {
     kpi: { successRate: { value: 97.3, delta: 1.2 } },
   };

   beforeEach(() => {
     vi.clearAllMocks();
+    vi.useFakeTimers();
+  });
+
+  afterEach(() => {
+    vi.runOnlyPendingTimers();
+    vi.useRealTimers();
   });

   // ... other tests ...

   it('returns error with type=no-provider when no handler registered', async () => {
-    vi.useFakeTimers();
     const noHandlerError = new Error('No handler registered for event: dashboard:query');
     (noHandlerError as any).code = 'NO_HANDLER';
     // Reject all retry attempts (initial + 4 retries)
     mockEventBus.request.mockRejectedValue(noHandlerError);

     const { result } = renderHook(() => useDashboardQuery(testQuery));

     // Flush all retry timers (1000, 2000, 3000, 5000ms)
     for (let i = 0; i < 5; i++) {
       await act(async () => {
         vi.advanceTimersByTime(5000);
       });
     }

     expect(result.current.error).toBeDefined();
     expect(result.current.error!.type).toBe('no-provider');
     expect(result.current.data).toBeNull();
-
-    vi.useRealTimers();
   });

🤖 Prompt for AI Agents

In `@apps/web-next/src/hooks/__tests__/useDashboardQuery.test.ts` around lines 76
- 96, Move vi.useFakeTimers() and vi.useRealTimers() out of the individual test
into test-scoped setup/teardown: add a beforeEach that calls vi.useFakeTimers()
and an afterEach that calls vi.runOnlyPendingTimers() then vi.useRealTimers();
in the test "returns error with type=no-provider when no handler registered"
remove the vi.useFakeTimers()/vi.useRealTimers() calls and keep the retry timer
advances (vi.advanceTimersByTime) as-is so mockEventBus.request rejection
behavior is exercised; reference mockEventBus.request and the test name to
locate the block and ensure the new beforeEach/afterEach surround all tests in
useDashboardQuery.test.ts.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

🧩 Analysis chain

🌐 Web query:

Vitest fake timers cleanup pattern best practices vi.useRealTimers

💡 Result:

What vi.useRealTimers() actually does

• vi.useFakeTimers() replaces timer APIs (and Date, etc.) until you switch back with vi.useRealTimers(). When you call vi.useRealTimers(), any timers that were scheduled while fake timers were active are discarded (they won’t run later on real timers). [1]

Recommended cleanup patterns (pick one)

Pattern A (most common): flush what’s pending, then restore

Use this when you want timers that were scheduled during the test to execute (including “hidden” timers from libraries), before returning to real timers.

import { beforeEach, afterEach, vi } from 'vitest'

beforeEach(() => {
  vi.useFakeTimers()
})

afterEach(() => {
  vi.runOnlyPendingTimers() // flush queued timers created under fake timers
  vi.useRealTimers()        // restore native timers
  vi.restoreAllMocks()      // restore spies/mocks
})

• runOnlyPendingTimers() runs timers that were initiated after useFakeTimers() (without recursively running timers created by those callbacks). [1]
• This mirrors the Testing Library guidance (“run pending timers” before “use real timers”) to avoid surprising behavior when code schedules timers you didn’t explicitly advance. [2]

Pattern B: hard cleanup (don’t run anything, just prevent leaks)

Use this when you don’t care about executing pending timeouts/intervals—only isolation between tests.

afterEach(() => {
  vi.clearAllTimers()  // drop all scheduled timers so they never run
  vi.useRealTimers()
  vi.restoreAllMocks()
})

• vi.clearAllTimers() removes all scheduled timers. [1]

Extra best practices / gotchas

• If you use fake timers to control Date/time, always restore in afterEach to avoid leaking mocked time into other tests (Vitest shows this pattern). [3]
• If you need to limit what gets faked (to reduce side effects), configure fakeTimers.toFake (and note Vitest defaults exclude nextTick and queueMicrotask). [1]
• Vitest passes options to @sinonjs/fake-timers; fakeTimers.shouldClearNativeTimers defaults to true, which helps avoid interference from timers that existed before faking began. [4]

Rule of thumb: if any library code might have scheduled timers, use Pattern A; if you just want strict isolation and don’t want queued callbacks to run, use Pattern B.

Sources:
[1] Vitest vi API (fake timers, runOnlyPendingTimers, clearAllTimers, useRealTimers)
[2] Testing Library: restore real timers + run pending timers guidance
[3] Vitest guide: Mocking Dates (restore timers in afterEach)
[4] Vitest config: fakeTimers / shouldClearNativeTimers

---

🏁 Script executed:

# First, let's examine the test file to understand the context
fd -t f "useJobFeedStream.test.ts" | head -20

Repository: livepeer/naap

Length of output: 115

---

🏁 Script executed:

# Look for patterns of fake timer usage in the test file
rg -A 2 "vi\.useFakeTimers|vi\.useRealTimers" --type ts

Repository: livepeer/naap

Length of output: 3339

---

🏁 Script executed:

# Check if there are other tests in the same file using fake timers
fd -t f "*.test.ts" -o "*.test.tsx" | xargs grep -l "useFakeTimers" | head -10

Repository: livepeer/naap

Length of output: 196

---

🏁 Script executed:

# Let's examine the full test file to see how it's structured and if it has beforeEach/afterEach
cat -n apps/web-next/src/hooks/__tests__/useJobFeedStream.test.ts | head -200

Repository: livepeer/naap

Length of output: 6740

---

🏁 Script executed:

# Check if there are other tests in the same file and their cleanup patterns
rg "describe|beforeEach|afterEach|it\(" apps/web-next/src/hooks/__tests__/useJobFeedStream.test.ts -A 1 | head -80

Repository: livepeer/naap

Length of output: 1090

---

Move fake timer setup/teardown to beforeEach/afterEach hooks to prevent timer leakage on test failure.

Currently, if an assertion fails before vi.useRealTimers() (line 163), fake timers leak into subsequent tests. Other tests in this codebase use beforeEach/afterEach for timer management (as shown in alertEngine.test.ts, processMonitor.test.ts, etc.), which is the established pattern. Move vi.useFakeTimers() to the existing beforeEach, and add vi.useRealTimers() (or vi.clearAllTimers() + vi.useRealTimers() per Vitest docs) to an afterEach hook. This ensures cleanup runs regardless of test outcome and aligns with the codebase convention.

🤖 Prompt for AI Agents

In `@apps/web-next/src/hooks/__tests__/useJobFeedStream.test.ts` around lines 143
- 164, The test "returns error when no provider registered" currently calls
vi.useFakeTimers() and vi.useRealTimers() inline, which can leak timers on
failures; move the vi.useFakeTimers() call into the existing beforeEach for this
test suite and add an afterEach that calls vi.clearAllTimers() and
vi.useRealTimers() (or at minimum vi.useRealTimers()) so fake timers are always
restored; update references in the file
apps/web-next/src/hooks/__tests__/useJobFeedStream.test.ts and ensure the test
body (useJobFeedStream hook test) no longer toggles timers itself.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🏁 Script executed:

# First, let's find and examine the sendgrid.ts file
fd -t f "sendgrid.ts" packages/plugin-sdk/src/

Repository: livepeer/naap

Length of output: 111

---

🏁 Script executed:

# Let's examine the full file structure and content to understand the issue
cat -n packages/plugin-sdk/src/integrations/email/sendgrid.ts

Repository: livepeer/naap

Length of output: 6181

---

🏁 Script executed:

# Also check for type definitions of EmailOptions and EmailRecipient
fd -t f "\.ts$" packages/plugin-sdk/src/integrations/email/ -x cat -n {}

Repository: livepeer/naap

Length of output: 6181

---

🏁 Script executed:

fd -t f "integrations.ts" packages/plugin-sdk/src/types/ -x cat -n {}

Repository: livepeer/naap

Length of output: 5496

---

🏁 Script executed:

fd -t f "services.ts" packages/plugin-sdk/src/types/ -x cat -n {}

Repository: livepeer/naap

Length of output: 25734

---

Fix sendTemplate to normalize email options and avoid invalid payloads.

sendTemplate directly accesses options?.from and options?.replyTo as EmailRecipient objects (lines 117, 119), which will serialize as { email: { email, name } } when sent to SendGrid, causing rejection. The send and sendHtml methods already handle this correctly via convertOptions(). Reuse convertOptions here to extract the email strings consistently.

🔧 Suggested fix

   async sendTemplate(
     to: string | string[],
     templateId: string,
     variables: Record<string, unknown>,
     options?: EmailOptions
   ): Promise<void> {
     const toArray = Array.isArray(to) ? to : [to];
+    const { from, replyTo } = this.convertOptions(options);
     
     const response = await this.request('POST', '/mail/send', {
       personalizations: [{
         to: toArray.map(email => ({ email })),
         dynamic_template_data: variables,
       }],
-      from: { email: options?.from || this.fromEmail || 'noreply@example.com' },
+      from: { email: from || this.fromEmail || 'noreply@example.com' },
       template_id: templateId,
-      reply_to: options?.replyTo ? { email: options.replyTo } : undefined,
+      reply_to: replyTo ? { email: replyTo } : undefined,
     });

🤖 Prompt for AI Agents

In `@packages/plugin-sdk/src/integrations/email/sendgrid.ts` around lines 87 -
102, sendTemplate is constructing the SendGrid payload using options?.from and
options?.replyTo as EmailRecipient objects, which serializes incorrectly; reuse
the existing convertOptions(options) helper to normalize EmailOptions into plain
strings and merge its result into the payload before sending. Update
sendTemplate to call convertOptions(options) and use the returned
from/replyTo/cc/bcc values (instead of directly accessing
options?.from/options?.replyTo), ensuring the payload matches how send and
sendHtml build their requests.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Unwrap data.comment in acceptAnswer to cover both response shapes.
createComment handles { data: { comment } }, but acceptAnswer does not. If the proxy returns data.comment, the returned Comment will be missing IDs.

✅ Suggested fix

-  const raw = json.data ?? json;
+  const raw = json.data?.comment ?? json.data ?? json;
   return normalizeComment(raw);

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	const json = await res.json();
	const raw = json.data ?? json;
	return normalizeComment(raw);
	const json = await res.json();
	const raw = json.data?.comment ?? json.data ?? json;
	return normalizeComment(raw);

🤖 Prompt for AI Agents

In `@plugins/community/frontend/src/api/client.ts` around lines 393 - 395, The
acceptAnswer return path currently passes the raw response into normalizeComment
without handling the nested shape { data: { comment } }; update the parsing in
the acceptAnswer flow (same area where json is parsed and normalizeComment is
called) to unwrap json.data.comment first, then fall back to json.data and
finally json (e.g. use json.data?.comment ?? json.data ?? json) so
normalizeComment receives the actual Comment object; mirror the behavior used by
createComment to ensure IDs are preserved.

[seanhanca]

no comments