Okay, the way state and atomicState work:
At app start, state is read from DB
During app execution, when state is read, the data is read from the state variable, no DB read
During app execution, when atomicState is read, the data is read from the DB synchronously
During app execution, when state is written, the data is written to the state variable, no DB write, flag is set for state usage
During app execution, when atomicState is written, the data is written to the DB synchronously, state is not written and becomes out of sync at this time
At app end, state is written to DB IF the flag is set during any state write/set <<< THIS IS WHERE THE APP FAILS
If you try to save an object into state, it will! Problem arises at end of app, when the state is serialized and saved to the DB. This is where to error occurs, state is not saved, app ends in silent error - no error whatsoever is exposed to the developer, whatever things app did may not actually execute, YMMV. I determined this empirically.
NOTE: Documentation says to not use both state and atomicState. I am. If you happen to use both state and atomicState, state may be written at the end of the app run, overwriting whatever you wrote during the app using atomicState. A workaround that works 99% of the time is: if you use atomicState to set an object, make sure you do this right before the app ends: state.object = atomicState.object <<< this will update the state to the value of atomicState allowing you to use both - may still break, since the read/write is not “atomic”. I do this to avoid using atomicState for everything - seems rather unprofessional and a resource hog.
@Jim can you please confirm this is the way it works? As I said, I figured this out empirically. If so, please update documentation to explain EventWrapper, DeviceWrapper, etc cannot be used with state. App dies silently leaving the developer confused. @slagle, @Aaron, @vlad, any input please?