fix(mercury_items): redirect on validation failure instead of rendering missing template

[sentry]

This PR addresses SURE-APP-19A by modifying MercuryItemsController#create.

Previously, when a mercury_item failed validation outside of a Turbo Frame request, the controller attempted to render :new, which resulted in an ActionView::MissingTemplate error because no app/views/mercury_items/new.html.erb template exists.

This change replaces render :new, status: :unprocessable_entity with redirect_to accounts_path, alert: @error_message, status: :see_other on line 437. This aligns the error handling for non-Turbo Frame requests with the existing success path (which redirects) and the Turbo Frame error path (which renders a partial, not a full template).

Fixes SURE-APP-19A

_{This PR was automatically generated by Sentry. You can adjust this setting at any time.}

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 1c87dde593

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Redirect failed creates back to provider settings

When Turbo is disabled or a client submits without a Turbo-Frame header, a validation failure now sends the user to the accounts index, but the Mercury connection form exists only on the provider settings page. The alert is shown, yet the user is taken away from the form and cannot correct the invalid input without manually navigating back; redirect this failure to settings_providers_path instead.

Useful? React with 👍 / 👎.

[jjmata]

Reviewed the diff — the create fix looks correct and consistent with the controller's existing redirect_to ..., status: :see_other pattern.

One related issue outside this diff: update's failure branch (app/controllers/mercury_items_controller.rb:476) still calls render :edit, status: :unprocessable_entity, but there's no app/views/mercury_items/edit.html.erb. A non-Turbo-Frame PATCH to /mercury_items/:id with invalid params would hit this branch and raise ActionView::MissingTemplate (500) — the same crash class this PR fixes for create. Might be worth applying the same redirect_to fix there for consistency, in this PR or a follow-up.

---

Generated by Claude Code

[jjmata]

Daily PR scan review for head 1c87dde5937e5207ec8e6926977384697e329c8d.

CI is green (Pull Request workflow run 32602141692, Pipelock Security Scan 32602141746), but I would not merge this yet.

1. app/controllers/mercury_items_controller.rb now redirects non-Turbo create failures to accounts_path. That avoids the missing new template, but it sends the user away from the Mercury/provider settings flow after a validation failure. Use the provider settings destination instead, such as settings_providers_path, so the alert lands next to the form they need to fix.

2. The same missing-template failure class still exists in the update path: invalid non-Turbo PATCH falls through to render :edit, status: :unprocessable_entity, and there is no app/views/mercury_items/edit.html.erb. Apply the same redirect pattern there, or explicitly split it into a follow-up if this PR stays narrowly scoped.

[sure-design]

Automated PR sweep: two issues flagged by Codex/@jjmata on 2026-08-23 remain open — the redirect on validation failure goes to accounts_path instead of settings_providers_path, stranding the user away from the form they need to fix, and the same MissingTemplate crash class still exists in the update/edit path, unfixed. No commits since (bot-authored, unassigned) — needs a human to pick this up.

---

Generated by Claude Code