Race condition on deleting stubs

[Kenny Yee]

Hi,

I can't find a way to reliably delete stubs when I have parallel tests running against the same impostor. 

The fundamental problem is the API to delete a stub takes an index, and those indexes change when an earlier stub is removed. For example,

If 3 tests appended its own stub, then test2 deletes its stub at index 1:

{

   "stubs:" [ { ...stub1 }, { ...stub2 }, {...stub3} ]

}

DELETE /imposters/<port>/stubs/1

{

   "stubs:" [ { ...stub1 }, {...stub3} ]

}

test3 loses its reference to stub3 since stub3 shifted from index 2 to index 1 (shown in second JSON) . When it tries to delete index 2, it errors. Because the stub indexes changes there is no unique identifier to reference a stub. 

It seems like either: (1.) indexes shouldn't shift when deleting a stub or (2.) mountebank should return some hash on add stub, that can be passed back to delete. Right now, add stub returns entire definition of the imposter, so it's cumbersome to parse and remember the index for each test. 

Thanks

[Brandon Byars]

Thanks Kenny. You're right that it requires a stable identifier (like your hash idea) to avoid the delete race condition. However, I think even that isn't a perfect solution:

• test1 calls the imposter. It assumes that the test data includes [stub1, stub2, stub3], and the test assertions assume a response from stub1 is returned
• test2 calls the imposter to delete stub1
• The imposter unexpectedly returns stub2 to test1

For some time, I was reluctant to allow API-driven mutations of the stubs array because it seems ripe for unexpected semantic race conditions like this. Even if you had a stable id to ensure you were deleting the stub you thought you were, would your test setup experience that type of race condition? If not, mind sharing why not to help me understand?

Thanks,

-Brandon

--
You received this message because you are subscribed to the Google Groups "mountebank-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mountebank-disc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mountebank-discuss/e58713d6-bbde-4c0c-bfbd-f60aa5e4caddn%40googlegroups.com.

[Kenny Yee]

Hi Brandon, appreciate you looking into this! 

I believe the situation where a test deletes a stub created from a different test, that the different test tries to reference later is a separate issue. 

Having a unique identifier on each stub solves a specific issue of tests being able to delete and also edit, their own stub(s). Right now, that's not possible for parallel tests. The use case is each test will create their own stub(s) and are responsible for their own cleanups when they complete, instead of having an infinite growing number of stubs. 

A hash actually makes it very unlikely for a test to delete another tests's stub. It's essentially guessing a very strong password. But even if a test does guess correctly, or we use indexes that don't shift as a unique identifier (easy to guess), this problem doesn't detract from the use case above.  

Best,

Kenny 

[Nicolas Erlijman]

HI, 

I know this thread is old, but I have the same issue. Is there any solution to this race condition adding and deleting stubs in parallel tests?