Ok, I have all the tests running, but I was working still against the couchdb I run on my debian stable box. It is kind of late tonight so I don't think I will do any more tonight, but tomorrow (Wednesday) I will install couchdb on my desktop machine (Ubuntu oneiric) and see if I can reproduce the error.
Also, figure out a way of passing the server name on the test command line and default it to localhost or something like that.
Ok, I installed couchdb on my desktop and now am getting the same error. I suspect it is because quickcheck runs sets in parallel... and when I went over the network it was slow enough that none actually ran in parallel...
Hmm, I guess I do too but only about 1 out of every 10 times I run the tests. 9 out of 10 pass with no errors and really occasionally I get the error conflict error. I have probably run it 50 times by now :)
Notice the last two entries have different process ids (12319 versus 12320) so two different processes are trying to run a test at the same time. This is really weird because this is now only a single action....
Well, I narrowed down the error. It looks like it really is a bug not just a problem with the tests, perhaps a bug in http-enumerator. See the new test I created, which fails 95% of the time.
It happens when you call couchDelete followed by a single call couchPut (see the new test I added). The single call to couchPut causes two PUTs to go out over the wire (verified with wireshark, two puts go out on two different ports) If you add any call like a call to couchRev for something else, it works 100% of the time.
(This was why it only showed up sometimes in the bigger tests, since it only happened if couchDelete was followed by couchPut.)
Not sure if it is a problem in http-enumerator or our use of it, but somehow a single call to couchPut is generating two actual HTTP requests.
As I see, Michael buried up to their ears in conduit and dependent packs and he probably will not do anything. I can send pull request to him (or you - if you like github). But, as I think it will require testing.
Actually, I am traveling for Christmas to my parents. I won't be back home until Tuesday, so can't test anything till then. Also, I plan on uploading the new version of couchdb-enumerator to hackage Tuesday or Wednesday... we can think if there is anything else to add or change...
Pulled your changes. I assume the change from RequestBodyEnumChunked to RequestBodyLBS was because of aeson 0.5? Also, I see you updated the lower bound to 0.5 on aeson. Did enough change that we can't support both 0.4 and 0.5?
Also, it looks like conduit is progressing along faster than thought. I plan on switching this package (and all my code) over to conduits once it lands in warp and yesod, which looks close in the future. But I think I will at least wait and not do anything until http-conduit is declared an a released state and uploaded to hackage.
I do plan on releasing this version of couchdb-enumerator tomorrow (Thrusday)
Yep. Aeson 0.5 uses text instead blaze-builder. Current (non-conduit) version of http-enumerator uses blaze-builder. But future version will be use text. According to my observations, blaze-builder is used less and less.
As far as conduits, I plan on converting over now that http-conduit is out, but won't do anything until probably the middle of January. I want to wait until WAI and yesod are converted over and released before I make a serious push to convert my code to conduits. Also, would be nice to make sure the API is mostly stable... although from what I read on the mailing list and such it seems like it is stable already.