Closed jupe closed 3 months ago
@jupe, yes you are right, did you have the same issue with 2 user accounts? I will take a look on it as soon as possible, but in the meantime there is a workaround, for example something like that: once the device is taken you can introduce a random time before proceeding with the "ADB connect [REMOTE_DEBUG_ADDRESS]
" and if that gives an error or it returns the message "already connected to [REMOTE_DEBUG_ADDRESS]
", you can consider that taking the device was an error, and you can go to the next device to see if it is free?
We did workaround already a bit different way: https://github.com/OpenTMI/stf-appium-python-client/pull/26 which was smallest effort without breaking my library API. Would be great if you have time to look at this more deeply and provide fix!
@jupe , it is normally fixed on #650 PR, let me know if that fit your use case ? I did not set a lock for other POST/DELETE API calls related to device object because I don't think it is relevant for now.
I'll test this (latest release) hopefully coming week.
What is the issue or idea you have?
Parallel identical api call for
**POST** /user/devices/{serial}
leads success for both requests. Expectation is that another would fail with 403:Device is being used or not available
even same account is calling it.Does it only happen on a specific device? Please run
adb devices -l
and paste the corresponding row. happens with any devicePlease provide the steps to reproduce the issue.
used docker image: devicefarmer/stf:3.6.4
call mentioned API twice in parallel. Below are simple python script to reproduce issue
What is the expected behavior? In our case we are running android tests parallel in CI. Each test job are encapsulated to own container so STF server are only common part of the system. I've developed python libraries (see list below) that makes stf usage easily, but this bug leads that parallel runs takes sometimes same device from stf which leading test failures.
Do you see errors or warnings in the
stf local
output? If so, please paste them or the full log here.It looks that group channel subscribing really fails under the hoods: