Response.json vs response.json() in @rails/request.js

ChatGPT Bugs
1

The issue is GPT’s repeated mistake when handling Rails’s @rails/request.js — specifically, its misunderstanding of how FetchResponse.json works compared to the native Fetch API.

I would like to use gpt its own declare the issue with you:

When using @railsrails/request.js in Stimulus controllers, response.json should be accessed without parentheses.

Example:

const response = await request.perform()
if (response.ok) {
  const body = await response.json
}

Unlike the standard Fetch API, @rails/request.js overrides the Response object.

Its .json property is already a Promise that resolves to the parsed JSON body,

so calling it as a function (response.json()) will result in undefined or errors.

In short:

  • :white_check_mark: Correct: await response.json

  • :cross_mark: Wrong: await response.json()• This is by design in @rails/request.js, not a bug.

  • FetchResponse replaces the native Response and changes how .json behaves. • The library should really highlight this difference, since it breaks years of muscle memory from standard JavaScript.

Also worth noting: this kind of nuance often slips past AI and code assistants.
Even large models tend to assume native Fetch semantics because @rails/request.js is relatively niche and under-documented.
It’s a good reminder that Rails has its own peculiar layers, and they’re not always reflected in general JavaScript knowledge bases.