New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
state file gets confused #115
Comments
Moving data between JSON and hashes means that you can end up with :foo and "foo" both in the same hash, which is bad. Use a mash so they are always the same. Closes facebook#115. Signed-off-by: Phil Dibowitz <phil@ipom.com>
Moving data between JSON and hashes means that you can end up with :foo and "foo" both in the same hash, which is bad. Use a mash so they are always the same. Closes facebook#115. Signed-off-by: Phil Dibowitz <phil@ipom.com>
Moving data between JSON and hashes means that you can end up with :foo and "foo" both in the same hash, which is bad. Use a mash so they are always the same. Closes #115. Signed-off-by: Phil Dibowitz <phil@ipom.com>
Now I re-read the code in #116 , I am perplexed. I am not confident that it actually does anything. outside of a minor formatting change, this is assigning The mash structure is cool, but I am not sure it helps here. I think a simpler solution to this problem is to flatten the key |
no, you silly man. That's what mashes do... they treat string and symbol keys as the same thing. That's literally the point of them, so it always collapses them and we only ever write out strings, and always ever read in strings without constantly converting manually. |
I get that mashes handle keys differently. That's not the issue. The issue I'm raising is that simply assigning a new mash to state before trying to read a json file / falling back on an empty hash. The resulting data type of state is always a hash not a mash as you intended. Example:
I don't think the code in #116 actually does anything. If anything, the solution here is even simpler:
This flattens all keys to strings, all the time. |
Of course it's JSON... but it collapses all the keys. Every time. That's the point of mashes. What's written out is JSON, it's read into a mash, the keys merge properly. You CANNOT find a case with the current code where you'll get a |
This is the whole reason that Chef wrote Mash. Let Mash do that for you so you're not doing it yourself. |
This commit demonstrates a bug in state handling. Every modification involves a read, modify, write. This unit test mocks out just enough to show that a state file with ssl -> true is read correctly, changed, then produces an invalid json file with two entries in the hash with the same key. This is the key issue as reported in facebook#115. ``` [malmond@devvm1846.vll1 ~/local/taste-tester] /opt/chefdk/embedded/bin/rspec . F Failures: 1) TasteTester::State should serialize changes correctly Failure/Error: expect(@buffer.string).to eq('{"ssl":false}') expected: "{\"ssl\":false}" got: "{\"ssl\":true,\"ssl\":false}" (compared using ==) # ./spec/taste-tester_spec.rb:20:in `block (2 levels) in <top # (required)>' Finished in 0.01544 seconds (files took 0.27334 seconds to load) 1 example, 1 failure Failed examples: rspec ./spec/taste-tester_spec.rb:6 # TasteTester::State should serialize changes correctly ``` Signed-off-by: Matthew Almond <malmond@fb.com>
This is to fix the issue reported in facebook#115. It is possible to modify `state.rb` to use Mash in a way that does merge keys properly. However this is more complex than neccessary. The existing code already uses `.to_s` on reads. Given a choice between the two approaches, I am chosing to keep the code simpler and remove the unneccessary import. Signed-off-by: Matthew Almond <malmond@fb.com>
This commit demonstrates a bug in state handling. Every modification involves a read, modify, write. This unit test mocks out just enough to show that a state file with ssl -> true is read correctly, changed, then produces an invalid json file with two entries in the hash with the same key. This is the key issue as reported in facebook#115. ``` [malmond@devvm1846.vll1 ~/local/taste-tester] /opt/chefdk/embedded/bin/rspec . F Failures: 1) TasteTester::State should serialize changes correctly Failure/Error: expect(@buffer.string).to eq('{"ssl":false}') expected: "{\"ssl\":false}" got: "{\"ssl\":true,\"ssl\":false}" (compared using ==) # ./spec/taste-tester_spec.rb:20:in `block (2 levels) in <top # (required)>' Finished in 0.01544 seconds (files took 0.27334 seconds to load) 1 example, 1 failure Failed examples: rspec ./spec/taste-tester_spec.rb:6 # TasteTester::State should serialize changes correctly ``` Signed-off-by: Matthew Almond <malmond@fb.com>
This is to fix the issue reported in facebook#115. It is possible to modify `state.rb` to use Mash in a way that does merge keys properly. However this is more complex than neccessary. The existing code already uses `.to_s` on reads. Given a choice between the two approaches, I am chosing to keep the code simpler and remove the unneccessary import. Signed-off-by: Matthew Almond <malmond@fb.com>
the state file gets the same key in it twice, sometimes;
Note 'ref' is there twice... in my case I think this is one of 2 problems causing tt to restart itself all the time.
The text was updated successfully, but these errors were encountered: