Loading
refactor(rate_limit): tighten Matcher per round-2 review
Address @reprazent's second-round review on !283: - KNOWN_HASH_KEYS narrows to %i[eq re]. The :equality alias is dropped before release (cheaper to keep the surface tight than to support an alias forever for marginal convenience). - The explicit "{regex: ...} -> use :re" rejection branch is gone. Nothing has shipped under :regex, so callers who pass it now hit the same generic "unknown type key" path as any other typo. - Length cap applies to both String and Regexp sources via source.to_s.length, since both are engineer-provided and the error fires at boot time anyway. Regexp#to_s wraps the source with a few non-printable chars, so the effective allowed source length is slightly under MAX_REGEX_SOURCE_LENGTH for Regexp inputs -- acceptable. - Matcher#match? for :re now coerces the identifier value via #to_s instead of guarding on is_a?(String). Lets callers match Integer status codes (e.g. {status: { re: '^5\\d\\d$' }} against status: 503), which was the concrete use case Bob raised. The earlier "quietly skip non-String values" semantics inverts: nil.to_s == "" can match an empty-string regex, 42 against /42/ matches, etc. Existing tests reframed accordingly; new positive cast scenarios added in matcher_spec and evaluator_spec. Co-Authored-By:Claude Opus 4.7 (1M context) <noreply@anthropic.com>