WA-VERIFY-112: verify Rails 7.1 ActiveRecord attribute API assumptions

core/test/lib/workarea/error_reporting_test.rb

@@ -0,0 +1,65 @@
+require 'test_helper'
+
+module Workarea
+  class ErrorReportingTest < TestCase
+    class ReporterDouble
+      attr_reader :calls
+
+      def initialize(raises: false)
+        @raises = raises
+        @calls = []
+      end
+
+      def report(error, handled:, severity:, context:)
+        raise StandardError, 'reporter failure' if @raises
+
+        @calls << {
+          error: error,
+          handled: handled,
+          severity: severity,
+          context: context
+        }
+
+        :reported
+      end
+    end
+
+    def test_report_forwards_to_rails_error_when_available
+      error = StandardError.new('boom')
+      reporter = ReporterDouble.new
+
+      Rails.stub(:error, reporter) do
+        result = Workarea::ErrorReporting.report(
+          error,
+          handled: true,
+          severity: :warning,
+          context: { service: 'rubygems.org' }
+        )
+
+        assert_equal(:reported, result)
+        assert_equal(1, reporter.calls.length)
+        assert_equal(error, reporter.calls.first[:error])
+        assert_equal(true, reporter.calls.first[:handled])
+        assert_equal(:warning, reporter.calls.first[:severity])
+        assert_equal({ service: 'rubygems.org' }, reporter.calls.first[:context])
+      end
+    end
+
+    def test_report_returns_nil_when_rails_error_is_unavailable
+      error = StandardError.new('boom')
+
+      Rails.stub(:error, nil) do
+        assert_nil(Workarea::ErrorReporting.report(error))
+      end
+    end
+
+    def test_report_swallows_reporter_failures
+      error = StandardError.new('boom')
+      reporter = ReporterDouble.new(raises: true)
+
+      Rails.stub(:error, reporter) do
+        assert_nil(Workarea::ErrorReporting.report(error))
+      end
+    end
+  end
+end

docs/rails7-migration-patterns/error-reporting.md

@@ -8,9 +8,9 @@ This is implemented by `ActiveSupport::ErrorReporter` and is intended to be
 **configured by the host application** (or an integration gem) to forward handled
 exceptions to a provider (Sentry, Bugsnag, Honeybadger, etc.).
 
-## Verification status (WA-VERIFY-044)
+## Verification status (WA-VERIFY-114)
 
-**Status: ✅ Complete — implemented and compatible.**
+**Status: ✅ Complete — audited and compatible.**
 
 Workarea implements `Workarea::ErrorReporting` as a thin wrapper around
 `Rails.error.report`. The wrapper is availability-guarded so it degrades
@@ -23,6 +23,23 @@ Workarea **does not ship with a bundled error reporting provider**.
 Instead, Workarea relies on the host application to configure an error reporting
 solution at the Rack / Rails level.
 
+## Audited integration points
+
+The audit found a small, additive integration surface only:
+
+- `core/lib/workarea/error_reporting.rb` provides `Workarea::ErrorReporting`, a
+  compatibility wrapper around `Rails.error.report`.
+- `core/lib/workarea/latest_version.rb`,
+  `core/lib/workarea/ping_home_base.rb`, and
+  `core/app/models/workarea/checkout/fraud/analyzer.rb` use that wrapper for
+  handled exceptions that Workarea intentionally rescues.
+- `storefront/app/controllers/workarea/storefront/errors_controller.rb` sets
+  `request.env['rack.exception']` for 500 responses so Rack-level reporters can
+  observe unhandled exceptions through the normal middleware path.
+
+No additional `ActiveSupport::ErrorReporter` subscribers, custom Rails error
+reporter configuration, or provider-specific integrations are present in core.
+
 Examples:
 
 - Storefront error pages set `request.env['rack.exception']` in
@@ -51,15 +68,23 @@ Host applications can configure Rails' error reporter via `config.error_reporter
 
 ## Decision
 
-**Adopted Rails 7.1's error reporting API as an additive, opt-in hook:**
+**Rails 7.1's error reporting APIs do not introduce a compatibility break for
+Workarea internals or extension points.**
 
 - Workarea calls `Rails.error.report` **only when available**.
 - Workarea does not require any provider.
-- Existing error handling continues to work unchanged.
+- Existing error handling and Rack-based reporting continue to work unchanged.
+- Extension points remain stable because host applications and plugins can opt
+  into `config.error_reporter` without needing Workarea-specific changes.
 
 This is useful primarily for *handled/swallowed* exceptions where otherwise the
 host app may never learn about the error.
 
+## Client impact
+
+**None expected.** Existing applications, plugins, and downstream integrations do
+not need code changes to remain compatible.
+
 ## Verification commands
 
 ```bash

docs/research/actionview-template-handlers-rails7-1-compat.md

@@ -0,0 +1,120 @@
+# ActionView Template Handler Rails 7.1 Compatibility
+
+**Issue:** WA-VERIFY-113 / workarea-commerce/workarea#1137  
+**Branch:** `wa-verify-113-template-handler-compat`  
+**Date:** 2026-03-21  
+**Conclusion:** No Workarea-side template handler breakage found for Rails 7.1.
+
+## Summary
+
+This audit checked Workarea for:
+
+- custom `ActionView` template handler registrations
+- nonstandard view rendering hooks that could depend on handler internals
+- existing template engines used by the app (`haml`, `jbuilder`, `builder`)
+
+Result: **Workarea does not register custom ActionView template handlers**, and the
+repo's view-layer extensions stay at the normal partial/render API level. No
+Workarea code changes are required for Rails 7.1 template handler compatibility.
+
+## What was searched
+
+Repo-wide targeted searches covered `core/`, `admin/`, and `storefront/` for:
+
+- `ActionView::Template.register_template_handler`
+- `ActionView::Template::Handlers`
+- `register_renderer`
+- `render_to_body`
+- `lookup_context`
+- `view_paths`
+- `render inline:`
+- direct `JbuilderTemplate` extensions
+- template engine usage (`.haml`, `.jbuilder`, `.builder`)
+
+## Findings
+
+### 1) No custom template handler registrations in Workarea
+
+Searches found **no** uses of:
+
+- `ActionView::Template.register_template_handler`
+- `ActionView::Template::Handlers`
+- custom handler classes/modules
+
+That means Workarea is not depending on deprecated handler registration APIs or
+single-arity handler implementations in its own code.
+
+### 2) HAML remains the primary template engine
+
+Current engine usage in the repo:
+
+- `793` `.haml` templates
+- `13` `.jbuilder` templates
+- `1` `.builder` template
+
+Workarea already documents HAML compatibility in
+`docs/research/haml-rails7-compat.md`.
+That research confirms `haml 5.2.2` exposes a Rails-compatible two-argument
+handler entrypoint:
+
+```ruby
+Haml::Plugin.call(template, source = nil)
+```
+
+That is the relevant Rails 7+ contract for template handlers.
+
+### 3) Jbuilder usage extends rendering behavior, not handler registration
+
+Workarea has two Jbuilder extensions:
+
+- `core/lib/workarea/ext/jbuilder/jbuilder_append_partials.rb`
+- `core/lib/workarea/ext/jbuilder/jbuilder_cache.rb`
+
+These modify `JbuilderTemplate` behavior via `prepend` / decoration, but they do
+**not** register a custom template handler or bypass normal ActionView rendering.
+They continue to operate through standard `@context.render(...)` and cache hooks.
+
+### 4) Nonstandard rendering hooks are limited and Rails 7.1-safe on inspection
+
+The only notable view lookup customizations found were standard `lookup_context`
+usage, such as:
+
+- checking for optional partials before rendering
+- verifying style guide template existence
+
+These calls use normal ActionView lookup APIs and do not depend on template
+handler internals.
+
+## Rails 7.1 appraisal status
+
+The repo contains `gemfiles/rails_7_1.gemfile`, pinned to `rails 7.1.5.1`, but
+it currently includes this note:
+
+> As of 2026-03-17, this appraisal does not resolve due to mongoid (< 8.0.7)
+> constraining activemodel to < 7.1, while Rails 7.1 pins activemodel 7.1.x.
+
+So a live Rails 7.1 smoke test for this area is presently blocked by dependency
+resolution unrelated to ActionView template handlers.
+
+## Compatibility result
+
+**PASS** — No Workarea-owned template handler compatibility gap was found for
+Rails 7.1.
+
+### Verified safe
+
+- No custom ActionView template handler registrations in Workarea
+- No Workarea-owned single-arity template handlers
+- HAML compatibility already documented and aligned with Rails 7 handler arity
+- Jbuilder customizations stay within public rendering/template APIs
+- `lookup_context` usage is standard and not handler-internal
+
+### Known limitation
+
+- Rails 7.1 runtime smoke-testing is currently blocked by the existing
+  `mongoid` / `activemodel` appraisal resolution issue, so this verification is
+  based on code audit plus existing HAML compatibility research
+
+## Client impact
+
+None expected.