form_with reverting to HTML processing only

[dvodvo]

Steps to reproduce

Alas, there is no clear, reliable way to reproduce the problem, aside from accessing the entire application.

What is occurring is that a number of form_with forms are invariably reverting to processing via HTML only, as if some switch was thrown at some point. However this is not consistent across the application. It appears to be constrained to a single specific class.

Actual behavior

Following are examples of form_with and different uses with the HTML rendering and the returned logs for the two actions (and two actions only) that require turbo stream responses for this class.

<%= form_with(model: @parti) do |form| %>
<form action="/partis" accept-charset="UTF-8" method="post"><input type="hidden" name="authenticity_token" value="[...]" autocomplete="off">
Started POST "/partis" for ::1 at 2024-05-11 11:33:08 +0200
Processing by PartisController#create as HTML

<%= form_with(model: @parti, local: false) do |form| %>
<form action="/partis" accept-charset="UTF-8" data-remote="true" method="post"><input type="hidden" name="authenticity_token" value="[...]" autocomplete="off">
Started POST "/partis" for ::1 at 2024-05-11 11:40:50 +0200
Processing by PartisController#create as HTML
Rendering partis/create.html.erb within layouts/parti

 <%= form_with(url: update_consumer_partis_url, data: { remote: true }) do |form| %>
<form data-remote="true" action="/partis/create_consumers" accept-charset="UTF-8" method="post"><input type="hidden" name="authenticity_token" value="[...]" autocomplete="off">
Started POST "/partis/update_consumer" for ::1 at 2024-05-11 12:03:49 +0200
Processing by PartisController#update_consumer as HTML
  Parameters: {"authenticity_token"=>"[FILTERED]", "name"=>"Abc", "consumer_id"=>"1", "id"=>"150", "commit"=>"confirm"}

whereas other classes seem to process by TURBO_STREAM as expected. not been fully determined (many actions have yet to be checked)

Started PATCH "/shopcategoryminors/update_translations" for 127.0.0.1 at 2024-05-11 12:10:42 +0200
Processing by ShopcategoryminorsController#update_translations as TURBO_STREAM

update further testing: movign the controller action to a different controller and the processing is, as expected, processing as TURBO_STREAM.

How can one debug the process from Started POST to Processing by ...Controller#update_consumer as HTML
and determine where the process veers off course? or what should one be looking for?

Expected behavior

as the default behaviour is to default to turbo_stream, that is the expectation.

System configuration

ruby "3.3.0"
gem "rails", "~> 7.1.3", ">= 7.1.3.2"

[yshmarov]

Are you sure that your controller action has a format.turbo_stream response?

If it is not found, it will try to respond with format.html instead.

P.S. data: { remote: true } has no effect in rails 7

[dvodvo]

Definitive.
I run the controller •without• mentioning format, in order to default processing the rails way ...
If there is no view with the turbo_stream format, the 'html' file is then rendered.
In both cases, however, the logging will be
Processing by PartisController#create as TURBO_STREAM .
Something in this controller is forcing the processing to got to HTML...

[smitssjors]

I belive rails determines the content type based on the Accept header. If it includes text/vnd.turbo-stream.html the request will be handled as a TURBO_STREAM.

You can check the request header using the browser or with logger.debug request.headers["Accept"] in the controller action.

[dvodvo]

well the content type is being established as HTML
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
and not the default TURBO_STREAM.

I've tried many variants, trying unsucessfully to override... Now <%= form_with( url: create_consumers_partis_path, data: {turbo: true}) do |form| %> which renders in HTML <form data-turbo="true" ... but it still processes to HTML...

So something is diverting the normal process.

update I worked on the assumption of some naming conflict: there are multiple classes who are compounds (Parti, ConsumerParti, GroupParti), as well as compounded named actions ('create_consumers') which might be generating routing confusion, and thereby diverting the intended processing method. Having eliminated potential conflicts derived from action names, the behaviour remains stuck to HTML processing for any action that regards the Parti, ConsumerParti, GroupParti classes

[dvodvo]

The naming conflict was the root problem, but not the one described above. A class attribute's name was the same of a class goverend by a has_many relationship (initially this had not been specified in the model). Once specified, the record was no longer creatable and the processing reverted to HTML.