Encapsulate namespace_reverse_stackable behind rescue-handler methods

[ericproulx]

Stacked on #2794 (targets fix/base-only-rescue-handlers). Rebase onto master once #2794 lands.

Follow-up to #2794. That bug happened because namespace_reverse_stackable — a store whose only purpose is rescue-handler maps — was a public attr_reader that two different files reached into with raw keys, so the base-only write and read could drift onto different stores.

Change

Make namespace_reverse_stackable protected (still used internally by inherit_from / copy_state_from / to_hash), and expose intent-revealing methods on InheritableSetting:

def rescue_handlers            # merged, child-scope handlers win
def base_only_rescue_handlers  # merged, child-scope handlers win
def add_rescue_handlers(mapping, subclasses:)

• Write (dsl/request_response.rb): the handler_type branch collapses into add_rescue_handlers(mapping, subclasses: rescue_subclasses).
• Read (endpoint.rb): error_middleware_options calls ns_stack.rescue_handlers / .base_only_rescue_handlers; the child-precedence merge moves out of Endpoint onto InheritableSetting, and the three Endpoint privates from Fix base-only rescue handlers never firing #2794 go away.

Now one place knows the key, the store, and the merge — the write/read can't drift apart again.

Tests

The reverse-ordering behaviour is already covered by ReverseStackableValues' own spec (14 examples), so the InheritableSetting specs that poked subject.namespace_reverse_stackable[...] are replaced with tests for rescue_handlers / base_only_rescue_handlers / add_rescue_handlers (including nested-scope override). request_response_spec assertions switch from the raw store to the named readers.

Full suite: 2353 examples, 0 failures. RuboCop clean.

🤖 Generated with Claude Code

[github-actions]

Danger Report

No issues found.

View run