Add asyncio.Lock mutex to _request

[rudcode]

With this change if there is simultaneous request to the same url at the same time, it will only fetch the url once and the rest is feeded from cache

Open for any feedback

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 97.26%. Comparing base (ac512b8) to head (79bbefe).
Report is 6 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #226      +/-   ##
==========================================
+ Coverage   97.22%   97.26%   +0.03%     
==========================================
  Files          10       10              
  Lines        1010     1022      +12     
  Branches      171      173       +2     
==========================================
+ Hits          982      994      +12     
  Misses         18       18              
  Partials       10       10              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[alessio-locatelli]

@rudcode Thank you for the Pull Request. Could you please rebase and resolve merge conflicts?

I think that the code works and I have no remarks, but it would be nice to add a test because a non-working locking will not fail CI. Something like:

# 1. You need to mock `Backend.write()`.

# 2. Then call the same URL concurrently.
await asyncio.gather(*[session.get('http://localhost:8080/') for _ in range(10)])

# 3. Assert that `write()` was called only once.
mocked_bachend_write.assert_called_once()

Technically I could merge after adding a test, but I will wait for Jordan Cook's approval in case he decides to reject the PR or request changes.

[rudcode]

Hi @olk-m, okay, I'll rebase and try to add the test for this change. Thank you for the feedback, really appreciate it.

[JWCook]

Looks like this auto-closed because your fork's main is now the same as this repo's main, but feel free to reopen this or create a new PR.

I'm fine with adding a lock for identical requests, as long as it doesn't impact concurrent performance and there are tests added for the new behavior.

[JWCook]

@olk-m Is this basically the same approach you were planning to take for #903?

[alessio-locatelli]

@olk-m Is this basically the same approach you were planning to take for #903?

Yes, although I did not have an implementation idea, this functionality is something I was thinking of adding in the future.