Update test dependencies and fix Next.js API route compatibility

[dex-the-ai]

Summary

• fold the next-test-api-route-handler upgrade from Dependabot PR Bump cookie and next-test-api-route-handler #186 into a single Dex-maintained branch
• remove the direct uuid dependency instead of carrying the breaking uuid@14 jump from PR Bump uuid from 9.0.1 to 14.0.0 #194, using Node's built-in randomUUID() in the API route and tests
• fix the Pages Router tests for the current next-test-api-route-handler pagesHandler API and correct the GET test coverage
• fix pages/api/user.js so it accepts either parsed object bodies or raw string bodies, and make the GET query path use request-plus consistency so fresh writes are visible to the query tests

Verification

• npm run init-db:default
• npm test
• npm run check
• cp .env.default .env.local && npm run init-db:local
• npm run load-sample-data
• source .env.local && npm run build
• PORT=3001 npm run start
• manual API walkthrough against the running app: POST /api/user → GET /api/user?search=dex → DELETE /api/user?pid=<created-id>

Evidence

• tests now pass locally after the dependency changes (4 passed / 6 assertions)
• the built app handled a real create/search/delete flow locally after the body parsing fix
• the home page was captured with reviewer-facing media below

Media evidence

• Captured surface: local Next.js quickstart home page running from the combined branch
• Captured flow: page load plus a short home-page walkthrough, alongside a direct API create/search/delete verification

Screenshot

Video

Open the walkthrough video

Key verification notes

• next-test-api-route-handler@5.0.5 pulls in the updated cookie@1.1.1 chain that was failing in PR Bump cookie and next-test-api-route-handler #186 until the tests were moved to pagesHandler.
• uuid@14 was failing under Jest because of the ESM-only distribution path. Replacing the direct dependency with node:crypto's randomUUID() keeps the route/test behavior intact while removing the incompatible package entirely.
• npm run load-sample-data logs DocumentExistsError: document exists when the sample docs are already present; the app still builds and the manual CRUD verification succeeds.
• Local run artifacts: tutorial-maintenance/runs/couchbase-examples__nextjs-quickstart/2026-05-28-combined-pr/

Notes

• This PR is intended to supersede Dependabot PRs Bump cookie and next-test-api-route-handler #186 and Bump uuid from 9.0.1 to 14.0.0 #194 with one verified branch.
• npm audit still reports 2 moderate vulnerabilities through next -> postcss; the suggested auto-fix would downgrade Next.js to 9.3.3, so I left that out of scope for this pass.

[dex-the-ai]

Owner ping for this maintenance PR: @ejscribner

Requesting review from the manifest-listed owner(s) where GitHub does not already show a pending review request.

[vercel]

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

Project	Deployment	Actions	Updated (UTC)
couchbase-nextjs-quickstart	Ready	Preview, Comment	May 28, 2026 1:05am
nextjs-quickstart	Ready	Preview, Comment	May 28, 2026 1:05am

[gemini-code-assist]

Code Review

This pull request replaces the external uuid dependency with Node's native node:crypto randomUUID, updates next-test-api-route-handler to version 5.0.5 (updating test parameters accordingly), refactors request body parsing in the API handler, and adds scanConsistency: 'request_plus' to Couchbase query options. The reviewer feedback suggests wrapping the JSON parsing in a try...catch block to gracefully handle malformed payloads and making the scanConsistency option configurable via environment variables to prevent performance bottlenecks in production.

[gemini-code-assist]

Parsing req.body directly using JSON.parse without a try...catch block can cause the API route to crash or return a 500 Internal Server Error if the client sends malformed JSON. It is safer to wrap the parsing in a try...catch block and return a 400 Bad Request status code with a clear error message.

  let body = null;
  if (req.body) {
    if (typeof req.body === 'string') {
      try {
        body = JSON.parse(req.body);
      } catch (error) {
        return res.status(400).json({ statusCode: 400, message: 'Invalid JSON body' });
      }
    } else {
      body = req.body;
    }
  }

[dex-the-ai]

Fixed in 39599c4. The route now accepts either parsed object bodies or raw string bodies, and malformed JSON returns a 400 instead of falling through to a server error. I re-ran npm test, npm run check, and a local invalid-JSON POST against the built app.

[gemini-code-assist]

Using scanConsistency: 'request_plus' unconditionally in production can cause significant performance bottlenecks because Couchbase must wait for the indexer to catch up with all recent mutations before executing the query. It is recommended to make this configurable (e.g., via an environment variable) so that it is only enabled during tests or when strictly necessary, defaulting to undefined (which uses the default not_bounded consistency) in production.

Suggested change

	const options = {
	scanConsistency: 'request_plus',
	const options = {
	scanConsistency: process.env.COUCHBASE_SCAN_CONSISTENCY || undefined,

[dex-the-ai]

Fixed in 39599c4. I kept request_plus for the Jest path and made production use opt-in consistency via COUCHBASE_SCAN_CONSISTENCY, so we are not forcing stronger query consistency on every runtime request. I also re-ran the local create/search/delete walkthrough with the env override to confirm the intended test-style flow still works.

[dex-the-ai]

Pushed one more follow-up commit (c6432b0) after GitHub Advanced Security flagged the POST response path. The API route now uses explicit JSON responses throughout, which should address the reflected-XSS CodeQL alert without changing the route contract. I re-ran npm test, npm run check, and the local build/start + create/search/delete/invalid-JSON walkthrough after that change.