I haven't produced a test case, but I have traced through the logic in ZStorm and the transaction module. If an exception is raised by zstorm.StoreDataManager.commit() during txn.commit(), the transaction machinery will invoke zstorm.StoreDataManager.abort() which rollback on the store, setting the state to RECONNECT if the store is not connected.
I cannot locate a code path where afterCall() will leave the stores in a disconnected state.
I haven't produced a test case, but I have traced through the logic in ZStorm and the transaction module. If an exception is raised by zstorm. StoreDataManage r.commit( ) during txn.commit(), the transaction machinery will invoke zstorm. StoreDataManage r.abort( ) which rollback on the store, setting the state to RECONNECT if the store is not connected.
I cannot locate a code path where afterCall() will leave the stores in a disconnected state.