ruby-grape / grape / 30693032897 / 6

97%

master: 97%

Pull #2841

github

Give point-in-time copies their own stackable arrays

InheritableSetting#point_in_time_copy copied a scope's stackable store
shallowly, so the per-key Arrays stayed shared with the source. A
registration made after an endpoint was defined therefore still reached that
endpoint -- but only when the key already held a registration at the time the
copy was taken, since otherwise #stack allocated a fresh Array on the source
alone.

That made the outcome depend on something the API never expressed:

    use Middleware1
    get('/x') { }
    use Middleware2   # applied to GET /x

    get('/x') { }
    use Middleware2   # did NOT apply to GET /x

Two APIs stating the same thing, behaving differently. Not a deliberate
"late registration" feature -- helpers defined after an endpoint already did
not leak, because they resolve down a different path.

Dup the Arrays as well as the Hash holding them. A copy is a point in time:
what the source registers afterwards must not reach it. Inheritance is
untouched -- it resolves by walking #parent, so a scope still sees values an
enclosing scope gains later, which is what the existing "decouples namespace
stackable values" spec actually exercised (its value lives on the parent, so
no Array was ever shared and it passed either way).

Boot cost is negligible: 300 endpoints under scopes carrying middleware,
helpers and filters allocate 1800 more objects (+0.4%) with no measurable
change in time, all at definition time.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

311 of 1283 branches covered (24.24%)

Branch coverage included in aggregate %.

2684 of 3870 relevant lines covered (69.35%)

5.27 hits per line