Description of problem: here is what I think is happening. if (call == queue.get or call == up2date.login): if call.has_caps: server_in_db.set_caps(call.caps) else: server_in_db.set_caps(None) else: if call.has_caps: server_in_db.set_caps(None) else: # dont change the caps pass aka, it looks like if I make a call thats not queue.get or up2date.login, and I include caps info, it ignores the caps info I actually send, and instead nulls the caps. It also seem like, if I make any call, and dont include caps, it nullifies the caps. It seems like if the last call isnt a queue.get or up2date.login, then the caps are always going to be nullified. Which is kind of broken.
Checked the code, I only update the capabilities in up2date.login and queue.get. I don't touch the client capabilities from anywhere else (do a grep on update_client_capabilities). The capabilities are extracted from a global flag that is set by calling set_client_capabilities. set_client_capabilities is called from apacheHandler.py in the header parsing handler. It is arguable if "no capabilities from the client" means the client didn't send them (in queue.get/up2date.login) or it doesn't support capabilities anymore (older OS, or downgrading up2date). Donno. I can't really see how the above-mentioned scenario would work. I'll have to test a bit...
I could be wrong, but thats the behaviour I was seeing after a couple hours of testing. Basically, if I send up caps info with any call other than queue.get or login(), the caps get nullified. no caps in queue.get or login nullifying the store caps is fine. Even nullifying it on other calls might be fine. But nullifying it when the caps are sent seems wrong.
hmm, I thought perhaps I was sending up the wrong systemid on the login, but that does not appear to be the case. And I still get the same behaviour.