What is happening here is that the latency introduced by the poll is causing the client to receive the response from its "commit" before a previously queued pushed message to that client. By the time it receives the pushed message, it is "stale" - i.e. the previous version is not accurate anymore. We should be sending those queued messages to the client before the client processes the response to its operation. Thus the client would receive notification of the conflict two times in this case but it would be the same conflict so you would only have to resolve it once.
The only workaround I can think of right now is to resolve that second (stale) conflict using "acceptClient" without reporting it to the user. The problem though is knowing when this is a stale conflict versus a real new conflict. There is a timestamp in the message which theoretically could be used to detect that but it is pretty tricky so I'm not sure I'd recommend trying this workaround. I am working on a fix now... once it is ready we could investigate the possibility of turning it into a hotfix. Sorry for the problems and thanks for reporting this issue. Jeff -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/flexcoders/join (Yahoo! ID required) <*> To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
