Message sequencing allows Marionette to provide an asynchronous,
parallel pipelining user-facing interface, limit chances of payload
race conditions, and remove stylistic inconsistencies in how commands
and responses are dispatched internally.
Clients that deliver a blocking WebDriver interface are still be expected
to not send further command requests before the response from the last
command has come back, but if they still happen to do so because of
programming error or otherwise, no harm will be done. This will guard
against bugs such as bug 1207125.
This patch formalises the command and response concepts, and applies
these concepts to emulator callbacks. Through the new message format,
Marionette is able to provide two-way parallel communication. In other
words, the server will be able to instruct the client to perform a
command in a non ad-hoc way.
runEmulatorCmd and runEmulatorShell are both turned into command
instructions originating from the server. This resolves a lot of
technical debt in the server code because they are no longer special-cased
to circumvent the dispatching technique used for all other commands;
commands may originate from either the client or the server providing
parallel pipelining enforced through message sequencing:
client server
| |
msgid=1 |----------->|
| command |
| |
msgid=2 |<-----------|
| command |
| |
msgid=2 |----------->|
| response |
| |
msgid=1 |<-----------|
| response |
| |
The protocol now consists of a "Command" message and the corresponding
"Response" message. A "Response" message must always be sent in reply
to a "Command" message.
This bumps the Marionette protocol level to 3.
r=dburns
r=jgriffin
The Python client sends a `max_length' command parameter to multiAction,
but the Marionette server looks for `max_len'. This likely a regression
from a refactor.
r=dburns
Note that the web platform tests don't actually have quite the behavior they're
expected to per the spec yet. They will get adjusted later on as we add
subclassing support to Promise.resolve and Promise.prototype.then.
This makes it clearer that really it's the same thing as FINAL_TARGET,
with preprocessing.
We still keep DIST_FILES in backend.mk because it's shorter and doesn't
really matter.
Metrics submission in mozharness fails gracefully if there's a problem, but it
fails too early now that we're logging perherder data. This moves the guard
against repeatedly failing to submit to influx so that we will log
PERFHERDER_DATA even when influxdb submission fails.
