New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
form_with reverting to HTML processing only #51786
Comments
Are you sure that your controller action has a If it is not found, it will try to respond with P.S. |
Definitive. |
I belive rails determines the content type based on the You can check the request header using the browser or with |
well the content type is being established as HTML I've tried many variants, trying unsucessfully to override... Now 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 |
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. |
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.
whereas other classes seem to process by TURBO_STREAM as expected. not been fully determined (many actions have yet to be checked)
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
toProcessing 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"
The text was updated successfully, but these errors were encountered: