I had another look at that. My thinking was that moving the entire logic to get the access code and exchange it for the token into a single dialog, which we show.

The idea was that because of authenticationRequired returning immediately fails the request or retries it we could maybe have a single dialog that we run with exec() and which handles everything. Then upon exec() returning we have the access code, and maybe can inject it for all still pending requests.

But this does not work, because oauth requires additional web requests. And while authenticationRequired is running, no further network requests are run. So with the current webservice module based on QNetwork this just won't work to our satisfaction.

At a minimum we would need to handle this not with the authenticationRequired signal, but have our own handling of the 403 response. It definitely requires a refactoring of the network access.

@zas: This is not as easy as I had hoped, I know understand what you meant. I had assumed all the requests would trigger the dialog immediately so we just have to make sure to not open multiple simultaneously, but actually processing of further requests seems to halt while the first dialog gets opened and the next dialog gets shown after the previous got closed.

I thought about making this dialog unique, not showing it again if it is already open. Something like we did in https://github.com/metabrainz/picard/blob/ee5a429c626c6f3b4be2476d70cccc5ee90b7262/picard/ui/mainwindow.py#L892

Since all requests possibly requiring authentication are queued before authentification, each of them triggers authenticationRequired signal, connected to https://github.com/metabrainz/picard/blob/ee5a429c626c6f3b4be2476d70cccc5ee90b7262/picard/ui/mainwindow.py#L1142

Also I think we have the same issue with https://github.com/metabrainz/picard/blob/ee5a429c626c6f3b4be2476d70cccc5ee90b7262/picard/ui/mainwindow.py#L1159

Not really sure how we should fix that. Ideas?