Change name of "release" method in delayed logs handler

[djmattyg007]

The previous name of this method overrode a method with the same name in
the parent class that was related to lock acquisition. This was being
called internally by python logging code. Instead of releasing the lock,
this will have been accidentally dumping logs gathered before they were
ready to be handled. From what I can tell, this was happening just
before we manually called release(). This would give the appearance that
these logs were not being captured when in fact they were.

This fixes #1958

[codecov]

Codecov Report

Merging #1960 (3d8aa4d) into develop (284253c) will increase coverage by 0.10%.
The diff coverage is 50.00%.

@@             Coverage Diff             @@
##           develop    #1960      +/-   ##
===========================================
+ Coverage    76.87%   76.97%   +0.10%     
===========================================
  Files           55       55              
  Lines         4713     4713              
===========================================
+ Hits          3623     3628       +5     
+ Misses        1090     1085       -5     

Impacted Files	Coverage Δ
mopidy/internal/log.py	31.81% <50.00%> (ø)
mopidy/audio/actor.py	60.68% <0.00%> (+1.13%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 284253c...3d8aa4d. Read the comment docs.

[kingosticks]

So, why don't I see this issue?

EDIT: Is this just a race condition issue? I'm very surprised I didn't notice it missing from anyone's logs on the user forum.

EDIT EDIT: maybe something related to using venv instead of our usual virtualenv?

[djmattyg007]

Yeah I think there's a multitude of possible factors. Different version of python, different virtualenv setup, ability to access the keyring to find configuration, different Linux distribution C runtimes even? I'm not familiar with how python's built-in locking primitives work.

To be honest I'm not really sure how it could be happening at all, as from what I can tell handler.acquire() and handler.release() are only called by handler.handle(), which is also overridden. It's definitely happening though, and simply renaming the method 100% resolves the issue for me.

In general though it's probably a good idea to avoid overriding these kinds of methods in stdlib classes. It's difficult to see a downside from making this change.

[kingosticks]

I have no problem with the change, it's definitely a bug and not our intention to override release. I was trying to understand it fully with the aim of patching the test hole.

[kingosticks]

The test hole around logging is, for want of a better word, gaping. We can't worry about that here.

[kingosticks]

Thanks for drilling down and finding this.

[djmattyg007]

The test hole around logging is, for want of a better word, gaping. We can't worry about that here.

I did look for some testing code, and realised I wasn't sure how to test code that interacts with python's stdlib logging mechanism.

Thanks for drilling down and finding this.

Thank you and @jodal for writing such an amazing piece of software! It's genuinely changed the way I listen to music and formed the backbone of my multi-room music setup.

[kingosticks]

I can't take credit for much, I'm a relative new-comer. But I am glad you find Mopidy useful!

[kingosticks]

Oops, this never made it into the changelog

EDIT: cancel that, it did. I am blind.