I just tracked down an obscure bug related to saving records. In LABKEY.ext.Store, when a record is submitted to the server, a property called 'saveInProgress' is added to each client-side Ext record. This makes sense. However, when you call getChanges(), the method that builds the commands to send to the sever, the process looks like this:

-call getChanges(), which accepts an array of records as the argument
-the store iterates over these records and builds the object of commands to commit to the server
-if any of these records has saveInProgress=true, then it skips it. Fine behavior, except it does this silently. Therefore if you are in a situation where you try to commit X records, where some already have a transaction in progress, it will drop some of your records without warning. assuming the saving of the other records worked, it fires the commitcomplete event as if everything was normal.

there are ways to work around it, like listening for the beforecommit event and comparing the number of records you tried to save against the commands being sent to the server, but it seems like the store should provide something more verbose when it decides to change the intended plan.