ruby-grape / grape
97%
master: 97%

LAST BUILD BRANCH: fix/adversarial-sweep-2026-08
DEFAULT BRANCH: master
Repo Added
Files 167
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst

LAST BUILD ON BRANCH fix/stackable-copy-aliasing
branch: fix/stackable-copy-aliasing
CHANGE BRANCH
x

coverage: 96.976%. Remained the same
30694720879

Pull #2841

github

ericproulx 
Give point-in-time copies their own stackable and rescue-handler stores

InheritableSetting#point_in_time_copy copied a scope's stackable store and
its rescue-handler maps shallowly, so the nested Arrays and Hashes 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 the writer
allocated a fresh store 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

and the same for rescue_from:

    rescue_from ArgumentError { }
    get('/x') { raise Boom }
    rescue_from Boom { }     # rescued GET /x

    get('/x') { raise Boom }
    rescue_from Boom { }     # did NOT rescue 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 nested stores 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
nothing 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>
Pull Request #2841: Give point-in-time copies their own stackable arrays

1196 of 1285 branches covered (93.07%)

Branch coverage included in aggregate %.

2 of 0 new or added lines in 0 files covered. (NaN%)

3807 of 3874 relevant lines covered (98.27%)

26802.97 hits per line

Relevant lines Covered
3874 RELEVANT LINES 3807 COVERED LINES
26802.97 HITS PER LINE
Source Files on fix/stackable-copy-aliasing

Recent builds

Builds Branch Commit Type Ran Committer Via Coverage
30694720879 fix/stackable-copy-aliasing Give point-in-time copies their own stackable and rescue-handler stores InheritableSetting#point_in_time_copy copied a scope's stackable store and its rescue-handler maps shallowly, so the nested Arrays and Hashes stayed shared with the source. A... Pull #2841 ericproulx github
96.98
30693032897 fix/stackable-copy-aliasing 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 therefor... Pull #2841 ericproulx github
96.98
30693017293 fix/stackable-copy-aliasing 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 therefor... Pull #2841 ericproulx github
96.98
See All Builds (3445)