Is it possible that the _changes subscription pool holds two _changes subscriptions to the same database?

[janl]

I’m investigating an issue where emails get sent twice via the email plugin.

I get an error log presumably after the second time the emails got sent, the plugin tries to updated the task document, but fails, because the doc is already is deleted.

I have not fully grokked changes_pool.js and task_manager.js yet, so I am asking stupid questions :)

To me it looks like a task is picked up twice and now I am looking how that can happen. I can confirm that there are no server restarts in between the sending of the emails.

One theory would be that it is possible for a database to have two changes listeners. It might be that changes_pool.js reduplicates already, but I haven’t gotten to verify or falsify that assumption, hence my question to @caolan :)

[janl]

https://github.com/hoodiehq/hoodie-plugins-manager/blob/master/lib/task_manager.js#L39 suggests that a source can only be subscribed once, but I’m not sure if that covers my case, or whether that has a bug.

I’m open for other theories, too :)

[caolan]

@janl the design is that it would only subscribe once to each source - whether or not that happens in reality is another question

[janl]

Hehe right :)

My thinking is maybe that on two _db_updates for the same database there is a race condition where a consumer is created and then another one before the isSubscibed() call comes back.

Not sure if this is thwarted by node's single-threadedness, though.

On 10.02.2014, at 11:44, Caolan McMahon [email protected] wrote:

@janl the design is that it would only subscribe once to each source - whether or not that happens in reality is another question

—
Reply to this email directly or view it on GitHub.

[caolan]

isSubscribed is synchronous, so that should be ok... however, there will be an async call between a db_updates event and requesting the changes from the server. It's possible that with two db_updates events in quick succession we'd request the same set of _changes twice.

Looking at the code though, I think it would put the changes request into the updated queue and any subsequent requests would not queue another update until it is placed back into the idle pool.

[caolan]

Perhaps we should come up with a test which fires db_updates events in quick succession and see what happens...

[janl]

@caolan would that be a case of calling exports.refreshDB(updated, idle, data.db_name); quickly in succession? (the tricky part might be setting up a test that allows all that to happen)