Async session creation

[christian-bromann]

As a cloud provider starting a WebDriver session can take a while for arbitrary reasons. Long session creation times are problematic for users as request libraries tend to time out after a while. Currently workarounds are used where you would respond with a 302 redirect, redirecting to the same resource. Having a way to asynchronously create a session would help to get rid of such hacky workarounds.

This patch was original authored by @shs96c during TPAC 2018. I would love to finally pick this up and bring it into the spec.

At a high level these would be the step to create an asynchronous session:

1. Send a request with same payload as for synchronous session requests to [POST] /session/async
   Response payload would be as follows:

   {
       "sessionCreationJobId": "6fcd0780e995bd50fedd330cd49d0531",
       "status": "queueing",
       "timeout": 600000,
       "requestedTime": 1601990778990,
       "events": [],
       "data": {}
   }

2. Regularly check for the status of the session creation job by making requests to [GET] /session/async/6fcd0780e995bd50fedd330cd49d0531
   Response payload once job finished loading would be

   {
       "sessionCreationJobId": "6fcd0780e995bd50fedd330cd49d0531",
       "status": "created",
       "timeout": 600000,
       "requestedTime": 1601990778990,
       "endedTime": 1601990878990,
       "events": [{ eventId: "eventId-1" }, { eventId: "eventId-2" }, { eventId: "eventId-3" }, { eventId: "eventId-4" }, ...],
       "data": {}
   }

3. If there is interest introspecting events happen while creating the job the user can query for an event id via [GET] /session/async/6fcd0780e995bd50fedd330cd49d0531/eventId-1
   Response payload for this request would contain

   {
       "eventId": "event-1",
       "time": 1601990778990,
       "type": "progress",
       "message": "...",
       "data": "...",
       "stacktrace": "..."
   }

Notes from Simon when he drafted this with my comments:

Should session creation progress be represented using “events” or “logs”?

Given that session creation progress is always connected to a point in time I would favor events as representation for it.

Should session creation jobs have multiple timeouts, for example overall job timeout and wait timeout?

One timeout for the maximal amount of time it should take to create a job is fine. Overall job timeout is set as session timeout.

Should we require representation of session creation attempts? (Compare AWS Batch Describe Jobs)

IMO attempts can be easier represented in the bindings implementation rather than having to spec this into the protocol.

Should we use a common suffix like Time for names of properties representing times? (e.g. the Appium event timings API uses the suffix Time but represents times using “JS timestamps”, presumably milliseconds as provided by Date.now, the AWS Device Farm Get Job endpoint uses no suffix, for example "started", the SauceLabs Get Tunnel endpoint uses no suffix, for example "last_connected". If we do use a suffix, should we specify the units, for example endedTimeMillis?

I propose how it is currently spec'ed with endedTime and requestedTime.

Questions:

• @shs96c it is not quite clear for me how the user receives the sessionId after the user has fetched a created async job, what am I missing?

---

Preview | Diff

[shs96c]

This looks useful, and a good start. Thank you for picking this up.

[shs96c]

While I can see the reasoning for this, it might be useful to be able to get the cancelled or failed event for inspection.

[shs96c]

I think it's legit to just send the empty list as it just means that there have been no events, right?

[AutomatedTester]

I can't see a link to tests so adding requires test label

[jgraham]

I'd like to propose we start a new spec for this. The concern is that this doesn't seem like something browser vendors are likely to implement directly but something we could standardise with the implementation target being intermediary nodes. I know that's overhead, but unless there's a compelling reason that we actually need this in browser drivers I think it makes sense to seperate out so it's clear who the feature is aimed at.

[shs96c]

I'm fine with us speccing this out for intermediate nodes alone, but it should be specced out.

[christian-bromann]

@shs96c I addressed the comments and currently have only 2 remaining issue that I need input for:

1. How is the WebDriver user suppose to receive the session id from, once the session creation job moved to status created?

2. In your original draft you defined an endpoint to fetch the session creation job (/session/async/{session creation job id}) as well as specific events via /session/async/{session creation job id}/{event} where event is an event id that a user can receive from the events property of the session creation job. According to the spec it would only find one event that is matching the event id provided by the url path, you commented:

   I think it's legit to just send the empty list as it just means that there have been no events, right?

   which assumes it is able to fetch multiple events. I think the reasoning behind not allowing to just fetch all events is the same we have with logs however I don't think implementers will have as many job creation events as logs on a page. How about instead of fetching a specific event, to just have /session/async/{session creation job id}/events that fetches all events happening during job creation.

What do you all think?

[css-meeting-bot]

The Browser Testing and Tools Working Group just discussed Async Session Creation.

The full IRC log of that discussion

<AutomatedTester> topic: Async Session Creation
<AutomatedTester> Github Topic: https://github.com//pull/1552
<AutomatedTester> cb: So the idea is we async session creation job
<AutomatedTester> ... that has a defined set of events
<AutomatedTester> ... and it has the ability to check that session ID creation
<AutomatedTester> ... it has 3 endpoints
<AutomatedTester> ... the question is where does the session get the session ID back from
<AutomatedTester> ... if we allow a single event or all events
<AutomatedTester> q?
<simonstewart> q+
<AutomatedTester> jgraham: I think this should be targeted at browser implementations as it seems really good for areas where are a lot of latency like grid or cloud providers
<AutomatedTester> ... I also am not sure that I can say that this is hard to justify the time to implement it there
<AutomatedTester> ... my suggest is specify in a different spec
<AutomatedTester> ... or make it optional for end nodes
<AutomatedTester> q?
<AutomatedTester> ack jgraham
<AutomatedTester> ack simonstewart
<AutomatedTester> simonstewart: I think you're right it's important for grid and I see what you mean by resourcing
<AutomatedTester> ... in a new spec is overkill
<AutomatedTester> ... and we can definitely mark this as a _may_
<AutomatedTester> cb: The main thing for us to make sure that have enough time to get the machines ready at sauce and we don't need to have it like it is
<AutomatedTester> jgraham: I think the main use case is definitely yours and I dont think browser vendors should stop you from speccing it
<AutomatedTester> Resolution: Add this to webdriver http and mark the new command as a MAY
<whimboo> present +
<foolip> I have to run, thanks everyone! (son is calling)
<AutomatedTester> RRSAgent: bye
<RRSAgent> I see no action items
<AutomatedTester> oh dear
<AutomatedTester> I should ahve force it to make minutes
<RRSAgent> logging to https://www.w3.org/2020/10/28-webdriver-irc
<AutomatedTester> RRSAgent: make minutes v2
<RRSAgent> I have made the request to generate https://www.w3.org/2020/10/28-webdriver-minutes.html AutomatedTester
<AutomatedTester> it's lost the async stuff
<jgraham> Nope, all OK
<AutomatedTester> oh... just slow
<jgraham> RRSAgent: stop
<AutomatedTester> yay!
<jgraham> Yeah
<jgraham> RRSAgent: bye
<RRSAgent> I'm staying, jgraham; no access has been specified for the meeting record
<jgraham> RRSAgent: make logs public
<RRSAgent> I have made the request, jgraham
<jgraham> RRSAgent: bye
<RRSAgent> I see no action items
<AutomatedTester> stupid bot
<AutomatedTester> Zakim: bye
<jgraham> Zakim, bye
<Zakim> leaving. As of this point the attendees have been AutomatedTester, jimevans, shengfa, Honza, cb, jgraham, foolip, john_chen, brwalder, simonstewart, brrian, drousso, mathiasbynens
<jgraham> Zakim is the weird one :)

[christian-bromann]

Closing in favor of #1561