[🚀 Feature]: Killing Sessions via UI

[shmikkil]

Feature and motivation

We are using k8s grid 4 and have the pods up and running all the time. It's a hassle to delete the pods that're stuck when sessions time out or when end-users doesn't close their sessions after the tests were executed. Any way we can add this feature to delete/remove sessions via the UI Console by right-clicking each of these sessions and remove them? Thank You!

Usage example

Right click on individual session IDs that are long running and delete/remove them.

[github-actions]

@shmikkil, thank you for creating this issue. We will troubleshoot it as soon as we can.

---

Info for maintainers

Triage this issue by using labels.

If information is missing, add a helpful comment and then I-issue-template label.

If the issue is a question, add the I-question label.

If the issue is valid but there is no time to troubleshoot it, consider adding the help wanted label.

If the issue requires changes or fixes from an external project (e.g., ChromeDriver, GeckoDriver, MSEdgeDriver, W3C), add the applicable G-* label, and it will provide the correct link and auto-close the issue.

After troubleshooting the issue, please add the R-awaiting answer label.

Thank you!

[diemol]

This could make sense. However, I would only enable that feature if the Grid is password protected or under a specific flag. Otherwise, anyone could delete any session and this might be annoying in shared Grids.

Please note that it is only possible to stop idle sessions, if a session is stuck in a request, the request needs to timeout before any action can be taken. You can always tune the session timeout to reduce this type of situation.

[github-actions]

This issue is looking for contributors.

Please comment below or reach out to us through our IRC/Slack/Matrix channels if you are interested.

[shmikkil]

This could make sense. However, I would only enable that feature if the Grid is password protected or under a specific flag. Otherwise, anyone could delete any session and this might be annoying in shared Grids.

Please note that it is only possible to stop idle sessions, if a session is stuck in a request, the request needs to timeout before any action can be taken. You can always tune the session timeout to reduce this type of situation.

Awesome...Glad to hear that! And yes, just going with a default pwd at the moment. Come to think of it, perhaps we should have another enhancement request where there should be an ability for the admins to assign creds to a specific group that could delete/maintain while the end-users who run the tests to be assigned to another group that simply can access the sessions during runtime to view the execution via the UI as well. Would that be helpful?

[diemol]

This could make sense. However, I would only enable that feature if the Grid is password protected or under a specific flag. Otherwise, anyone could delete any session and this might be annoying in shared Grids.
Please note that it is only possible to stop idle sessions, if a session is stuck in a request, the request needs to timeout before any action can be taken. You can always tune the session timeout to reduce this type of situation.

Awesome...Glad to hear that! And yes, just going with a default pwd at the moment. Come to think of it, perhaps we should have another enhancement request where there should be an ability for the admins to assign creds to a specific group that could delete/maintain while the end-users who run the tests to be assigned to another group that simply can access the sessions during runtime to view the execution via the UI as well. Would that be helpful?

I do not think Grid should start managing user profiles and passwords, that requires storage and managing those credentials very carefully. For now, Grid offers basic auth with a single user and password. That type of feature is out of scope.

[shmikkil]

This could make sense. However, I would only enable that feature if the Grid is password protected or under a specific flag. Otherwise, anyone could delete any session and this might be annoying in shared Grids.
Please note that it is only possible to stop idle sessions, if a session is stuck in a request, the request needs to timeout before any action can be taken. You can always tune the session timeout to reduce this type of situation.

Awesome...Glad to hear that! And yes, just going with a default pwd at the moment. Come to think of it, perhaps we should have another enhancement request where there should be an ability for the admins to assign creds to a specific group that could delete/maintain while the end-users who run the tests to be assigned to another group that simply can access the sessions during runtime to view the execution via the UI as well. Would that be helpful?

I do not think Grid should start managing user profiles and passwords, that requires storage and managing those credentials very carefully. For now, Grid offers basic auth with a single user and password. That type of feature is out of scope.

Thanks for the clarification!

[krmahadevan]

@diemol - Basic question around this. If a session is stuck due to whatever reasons (for e.g., the client died/was killed) then wouldn't the session eventually timeout because the guava cache in LocalNode has a listener which seems to be triggering a delete session request for sessions that are about to be evicted.

• If this cleanup logic is assumed to be reliable (things can still go wrong when we attempted to fire a POST request to delete session) then when would we need this sort of an explicit cleanup ?
• Even if we were to provide that mechanism (by having the user call the delete session API) would that work because our cleanup would have cleaned up the slot to which this session was associated with ?

[diemol]

@krmahadevan yes, eventually the timeout will kick in and stop the session.

If this cleanup logic is assumed to be reliable (things can still go wrong when we attempted to fire a POST request to delete session) then when would we need this sort of an explicit cleanup ?

I see as the use case where a session was started with the wrong parameters and you do not want to wait until the timeout kicks in. An Appium session for example.

Even if we were to provide that mechanism (by having the user call the delete session API) would that work because our cleanup would have cleaned up the slot to which this session was associated with ?

The cleanup mechanism for timeout only kicks in when the timeout happens, so this new feature would just be a nice thing to have when one wants to stop the session.

[krmahadevan]

I see as the use case where a session was started with the wrong parameters and you do not want to wait until the timeout kicks in. An Appium session for example.

Ok. In that case, it would just boil down to invoking the DELETE session api (endpoint: /se/grid/node/session/{sessionId}, operation: DELETE) via a curl right ?

[diemol]

I see as the use case where a session was started with the wrong parameters and you do not want to wait until the timeout kicks in. An Appium session for example.

Ok. In that case, it would just boil down to invoking the DELETE session api (endpoint: /se/grid/node/session/{sessionId}, operation: DELETE) via a curl right ?

That also works. However, the idea would be to have it as an option from the UI (under a flag or so).

[shmikkil]

Any update on this enhancement request?

[diemol]

@shmikkil feel free to send a pull request to help us out! We are a group where most of the members are volunteers. If you need help to get started, please join our Slack channel https://www.selenium.dev/support/

[ksingha161]

until this is done is there a way to get all sessions related to a node uri ? Then we could just hit this api in a loop to delete all sessions @diemol
http://<node:uri>/se/grid/node/session/sessionId

[diemol]

You can send a DELETE to the Hub/Router. That is what driver.quit() does.

http://<hub:uri>/session/sessionId

[diemol]

Also, check the available endpoints here https://www.selenium.dev/documentation/grid/advanced_features/endpoints/

[karanjeetbirdeye]

Thanks, but for this sessionId is still needed. I'm just looking for a way to get all sessionId's.

[diemol]

Thanks, but for this sessionId is still needed. I'm just looking for a way to get all sessionId's.

Did you check what the status endpoint returns?

[karanjeetbirdeye]

Got it thanks, status endpoint contains the sessionId. Guess I can just parse it and pass it in the api. Thanks a lot.

[shah-shivam-410]

Hi @diemol , I tried something and want to test by building locally, since in standalone react server sessions wont be there.
Could you please share build guide resource, unable to find in repo.
I need to build react ui and grid and create standalone jar file.