I just wanted to let people know I recently filed CHEF-4596.
It’s a common thing in chef to call .to_hash on an attribute so you can loop
on it (iterating on attributes will usually give you not the thing you want
because of the way Chef autovivifies)…
Turns out in Chef 10… at least some versions… .to_hash will sometimes
de-dupe internal arrays of a hash. So if you have {:foo=>[‘a’, ‘b’, ‘a’]} in
your hash somewhere, what you’ll get is {:foo=>[‘a’, ‘b’]} and this could
seriously mess some people up in very subtle ways.
On Fri, Oct 4, 2013 at 2:33 PM, Phil Dibowitz phil@ipom.com wrote:
Hey guys,
I just wanted to let people know I recently filed CHEF-4596.
It’s a common thing in chef to call .to_hash on an attribute so you can
loop
on it (iterating on attributes will usually give you not the thing you want
because of the way Chef autovivifies)…
Turns out in Chef 10… at least some versions… .to_hash will sometimes
de-dupe internal arrays of a hash. So if you have {:foo=>[‘a’, ‘b’, ‘a’]}
in
your hash somewhere, what you’ll get is {:foo=>[‘a’, ‘b’]} and this could
seriously mess some people up in very subtle ways.
No, I believe that’s just because those examples iterate directly on
Attributes which is not allowed. If they called ‘.to_hash’ first, they’d be fine.
Which has a bug.
Steven Danna’s got a fix that seems to work for us, but… if someone was
relying on the ‘.uniq’ behavior of .to_hash, it’d be an unpleasant surprise,
so there’s some discussion going on.
