You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Appium will always use the preexisting session if it's available. This can cause problems if the session is on a different platform, using a different app, or really if there are any unexpected differences between the session described in a Flagpole test file and the session that is already running.
To reproduce:
Start a session outside Flagpole with Appium Inspector. Make that session happen on an iOS device
Run an Appium scenario using an Android device
We can implement checks to make sure the new opts are the same as those which are in use as capabilities. This will only check for the capabilities defined as opts in the scenario, and may miss some capabilities set in the preexisting session. However, it's likely that this will be enough for the majority of cases. Required capabilities will always be defined in a scenario; these capabilities include the automation and platform names, so an iOS session will never continue when trying to start an Android session.
We can further expand this to check the capabilities of multiple sessions to check which running session to use.
Alternatively, we can have Flagpole always close down any preexisting sessions before starting a new session. This may cause problems for running sessions in parallel, but it will guarantee that the session run on a particular scenario is exactly what is defined.
Or - we could just remove the ability to use an existing session and not close down any previous sessions. This would prevent the bug and allow parallel sessions to continue.
The text was updated successfully, but these errors were encountered:
Appium will always use the preexisting session if it's available. This can cause problems if the session is on a different platform, using a different app, or really if there are any unexpected differences between the session described in a Flagpole test file and the session that is already running.
To reproduce:
We can implement checks to make sure the new opts are the same as those which are in use as capabilities. This will only check for the capabilities defined as opts in the scenario, and may miss some capabilities set in the preexisting session. However, it's likely that this will be enough for the majority of cases. Required capabilities will always be defined in a scenario; these capabilities include the automation and platform names, so an iOS session will never continue when trying to start an Android session.
We can further expand this to check the capabilities of multiple sessions to check which running session to use.
Alternatively, we can have Flagpole always close down any preexisting sessions before starting a new session. This may cause problems for running sessions in parallel, but it will guarantee that the session run on a particular scenario is exactly what is defined.
Or - we could just remove the ability to use an existing session and not close down any previous sessions. This would prevent the bug and allow parallel sessions to continue.
The text was updated successfully, but these errors were encountered: