fix: Keploy unexpected behaviour with multiple dependencies

[charankamarapu]

Related Issue

• Info about Issue or bug

Closes: #1209

Describe the changes you've made

PS : The line numbers below are corresponding to the line numbers in the issue mentioned above.

1. Time out is encountered in generic dependency because of the logic of writing mocks into yaml in generic. If any other dependencies is appending the mocks and as mutex is put, the generic parser had to wait till it gets its turn to add mock. Due to this there is a delay in receiving data from client or server in generic parser which is causing client timeouts in generic. Added go routine in generic parser where keploy appends mocks in mocks.yaml. This is go routine logic is already present in other parsers expect in generic.

2. Increased similarity index to improve approximate matching in generic dependency.

3. Implemented sorting the mocks in the GetTcsMocks function according to the req timestamp of the mock.

4. There are two race conditions obeserved for this mismatch or misDelete of the mocks while matching.
   i) GetTcsMocks is returning the tcsMocks slice variable of the struct instead returning a copy it. So as different parsers update the tcsMocks it will be reflected in all other parsers suddenly and causes race conditions
   ii) Updating the tcsMocks via SetTcsMocks function after every parser get its match with a mock. Due to this there is a race condition.

Lets say

• parser a has read tcsMocks via GetTcsMocks
• parser b has read tcsMocks via GetTcsMocks
• parser a has deleted one mock after matching and updates tcsMocks via setTcsMocks
• parser b has deleted one mock after matching and updates tcsMocks via setTcsMocks

What happened here is the update made by parser a is lost.

To deal with these two race condition we are implementing a in-memory db go-memdb(which implements mvcc) and instead of resetting the tcsMocks after every match, we will delete that particular mock from the in-memory db. The only case where we can get a conflict is when some parser wants to delete the same mock which some other parser has already deleted. This cannot happen in different type of parsers. This can only happen in the case of connection pooling. In this case of conflict we will restart the matching process for that parser which faced the conflict. As we only have delete behaviour and not update we will not be implementing version based mvcc approach here.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Code style update (formatting, local variables)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

Please let us know if any test cases are added

Please describe the tests(if any). Provide instructions how its affecting the coverage.

Describe if there is any unusual behaviour of your code(Write NA if there isn't)

A clear and concise description of it.

Checklist:

• My code follows the style guidelines of this project.
• I have performed a self-review of my own code.
• I have commented my code, particularly in hard-to-understand areas.
• I have made corresponding changes to the documentation.
• My changes generate no new warnings.
• I have added tests that prove my fix is effective or that my feature works.
• New and existing unit tests pass locally with my changes.

Screenshots (if any)

Original	Updated
original screenshot	updated screenshot

[sweep-ai]

Apply Sweep Rules to your PR?

• Apply: All new business logic should have corresponding unit tests.
• Apply: Refactor large functions to be more modular.
• Apply: Add docstrings to all functions and file headers.

[Sarthak160]

@charankamarapu This looks good to me and the only method where I was updating mocks for change to MD5 Auth type has been also merged with Match function only, And that is used in case of latest postgres versions. Since test bench is also passing using that version only so we can conclude to be fine .

[gouravkrosx]

LGTM

[re-Tick]

LGTM