It is. This raises a very good point that I've found while testing early versions of this changeset. An exception during saving (soledad error, ioerror, or a bad payload -- not json-serializable, although I should check for that earlier) will lead to a situation in which the whole message cannot be reconstructed from its parts. Currently most of the accessor methods in LeapMessage are defending against null flag, body or attachment docs (simply logging a warning and returning None, just to be able to keep processing the list).

But in general the consistency problem is there. What about doing something like this:

1. Associate a "transaction uuid" with all the docs sent to be PUT (so we can quickly find the set). Mark the main document (the flags doc, currently) as "in transaction".
2. Wrap the four or more writes in a single payload object with that transaction id.
3. Do a try/except wrap about them, and
4. If everything went well, remove the "in transaction" flag from the flag document (retreiving by indexed transaction id in flags doc type).
5. Exclude any "in transaction" documents (interrupted, in the long term) from the FETCH results.
6. Enqueue them for retries?

Also, maybe we should include the raw message string in the first write, and remove it only after all the subdocuments have been successfully written. Otherwise we won't be able to attempt a second write.

Thoughts?