dupIfSource question

[Adrian Geană]

Hi, 

I've been seeing same operation being sent twice in my app using ShareJS, and it seems to happen when the client disconnects and doesn't get the ack back and resends the same op on reconnect. I was about to get my hands dirty writing a hack to reject double ops, but stumbled upon `dupIfSource` which seems to be a more elegant approach. 

The problem is I'm not sure what to send as value for this property. The comment says : 

# Dup detection works by sending the id(s) the op has been submitted with previously.

# If the id matches, we reject it. The client can also detect the op has been submitted

# already if it sees its own previous id in the ops it sees when it does catchup.

But then it compares the source of the op with the dupIfSource array, so I'm not sure what the 'id' of an op means : 

if oldOp.meta.source and opData.dupIfSource and oldOp.meta.source in opData.dupIfSource

The meta.source is the sessionId for the connection. 

The way I see it, I should keep a history of sessionIds on the client (I get a new one after a reconnect) and send that array as value for the dupIfSource parameter. 

I know this is probably obscure code, but if anyone stumbled on this or remembers it, I'd appreciate it :)

Thanks,

Adrian

[Adrian Geană]

OK, so it seems that the client Doc object actually handles the dupIfSource stuff, so there's no need to actually send a value when submitting an op. 

And I found out why it doesn't work. This is where the previous connection id is saved when going offline and having inflight ops : 

https://github.com/josephg/ShareJS/blob/master/src/client/doc.coffee#L83 The problem is that connection.id is undefined there (which makes sense, because the connection is disconnected), so dupIfSource will be [undefined] here : https://github.com/josephg/ShareJS/blob/master/src/client/doc.coffee#L135 

I'll probably come back with a pull request, but any suggestions are welcome.

[Joseph Gentle]

Sounds like a bug.

The whole client doc class has been rewritten for the next version.
I'll accept a pull request if you want, but I'd appreciate it if you
could test out the version in the rewrite branch.

Its really frustrating how difficult it is to test the reconnection
logic in sharejs. There's been a few bugs like this that people have
found recently. We need some proper tests. Maybe I'll add some code in
bcsocket to simulate a reconnect or something.

-J

> --
> You received this message because you are subscribed to the Google Groups
> "ShareJS" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sharejs+u...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>