Fix stale flash alerts
What does this MR do and why?
Fixes a stale flash alert that leaked into the next page load after a JSON commit failure.
In CreatesCommit#create_commit, flash[:alert] was set unconditionally before the respond_to block. On JSON/XHR requests (e.g. from the Web IDE modal), the flash was written to the session even though no view consumed it, causing the error banner to reappear on the user's next full page navigation -- duplicating the inline error already shown in the modal.
The fix moves flash[:alert] = inside the format.html block so it is only set for HTML requests. The failure_path.call resolution stays outside respond_to since both the HTML and JSON branches use it. HTML behavior for all six callers (blob_controller, tree_controller, commit_controller) is unchanged.
Changelog: fixed
How to set up and validate locally
Run the affected unit specs
# The modified JSON-path spec
bundle exec rspec spec/controllers/projects/blob_controller_spec.rb:599
# The full blob controller suite to catch regressions
bundle exec rspec spec/controllers/projects/blob_controller_spec.rb
# The concern itself (if you add a spec there)
bundle exec rspec spec/controllers/concerns/creates_commit_spec.rbManual verification in a local GDK instance
- Open any file in a project via the Web IDE or the single-file editor.
- Trigger a commit failure -- the easiest way is to set the branch to a protected branch you can't push to, or use an invalid commit message if validation is enabled.
- Confirm the inline error appears in the modal/editor as expected.
- Navigate to any other page (e.g. the project overview).
- Confirm no flash alert banner appears on that next page -- this is the regression you're fixing.
MR acceptance checklist
- This MR does not have a feature flag
- Tests added for the JSON path (
expect(flash[:alert]).to be_nil) and HTML path (flash is still set) - No documentation changes required (internal controller behaviour)
- No database changes
References
- Closes #618081 (closed)
Related to #618081 (closed)