Write down conversation about blowing up on persistence

Co-authored-by: Chris Todorov <[email protected]>
Co-authored-by: Adam Mueller <[email protected]>
Co-authored-by: Alistair Norman <[email protected]>
Co-authored-by: benjamin wil <[email protected]>
Co-authored-by: Harmony Bouvier <[email protected]>
Co-authored-by: Kendra Riga <[email protected]>
Co-authored-by: Senem <[email protected]>

Author: 8 people

TODO.md

@@ -11,3 +11,10 @@ In-Memory Order Updater TODO
 
 - [ ] Test coverage to ensure state changes aren't persisted (if someone changes current implementation)
 - [ ] Should we blow up if something tries to persist?
+  - Some thoughts from the initial conservation
+   - "By calling this in memory order updater, we are making a contract with the user that it will be in memory"
+   - "This is really something which theoritically should be covered in tests"
+   - "Our inMemoryOrderUpdater probably shouldnt take a persist true flag"
+   - thinking about other changes to solidus deep in the stack
+   - thinking about users configuring all the configurable classes
+