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

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.

This issue is looking for contributors.

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

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?

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.

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!

@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 ?

@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.

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 ?

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).

Any update on this enhancement request?

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

This issue is stale because it has been open 280 days with no activity. Remove stale label or comment or this will be closed in 14 days.

This issue is stale because it has been open 280 days with no activity. Remove stale label or comment or this will be closed in 14 days.

This issue was closed because it has been stalled for 14 days with no activity.