1
95%
master: 95%

Ran 14 May 2016 06:52PM UTC

Files 7

Run time 0s

Badge

Embed ▾

Committed 14 May 2016 06:42PM UTC coverage: 56.432% (+0.2%) from 56.25%

Job # 2.2.1

Build Type

push

travis-ci

Committed by

kytrinyx

Commit Message

Rewrite implementation of restore endpoint

We were intermittently getting very, very strange behavior in
production, which was very, very difficult to debug.

Some people were getting a (seemingly random) solution delivered
along with the exercise implementation. It was not the
solution that came from the example.rb file, it was some other user's
solution.

It turns out that the version of Ruby that is running on Heroku has
a different behavior for `dup` than the version running locally
on my machine.

We were calling dup on a cached exercise implementation, then mutating
the referenced "files" hash in the dup (not the original). However,
on Heroku, dup creates an object that has a reference to the same
hash, rather than also copying the hash, causing the original hash
to be mutated. The behavior on my local machine is creating a copy of
the hash, and so this behavior is not reproducible locally.

To test both locally and on heroku I verified the object_ids of the
files attribute of an implementation.

    Xapi.tracks['ruby'].implementations['gigasecond'].dup.files.object_id
    Xapi.tracks['ruby'].implementations['gigasecond'].files.object_id

Heroku had the same object_id, my local version did not.

Fixes exercism/exercism.io#2882
Fixes exercism/xruby#315

Coverage Stats

136 of 241 relevant lines covered (56.43%)

0.78 hits per line

exercism / x-api / 905 / 1
95%
master: 95%

README BADGES
x

Markdown

Textile

RDoc

HTML

Rst

Source Files on job 905.1 (2.2.1)

exercism / x-api / 905 / 1 95% master: 95%

README BADGES x

Markdown

Textile

RDoc

HTML

Rst

Source Files on job 905.1 (2.2.1)

exercism / x-api / 905 / 1
95%
master: 95%

README BADGES
x