Phil and I are tasked with producing a comprehensive set of system
tests for Proton Engine.
The aim is to produce a test suite that will execute against all
Proton implementations thus guaranteeing that all exhibit identical
behaviour and assuring conformance with the AMQP 1-0 specification.
This work has highlighted the need to define how Proton Engine API
behaves under error conditions.
To start a discussion, below we have identified below six different
types of error and posed a number of questions regarding the behaviour
of the Engine API. Thoughts?
We have identified two sources of test-cases:
A) AMQP specification (parts 1 and 2). For example, the spec states
(2.4.1) "the open frame can only be sent on channel 0" suggesting a
test case should exercise the path where Proton receives an Open on a
channel number other than 0, and similarly (2.4.2) "[The Close] frame
MUST be the last thing ever written onto a connection" suggests a test
case where Proton receives another frame after the receipt of Close.
B) Proton-API itself suggests test-cases. For example, what if a user
tries to bind a connection to more than one transport, opens too many
channels, or calls connection close on a connection that has already
Numbers 1-4 relate to the bottom half (i.e. the transport I/O functions):
1) bytes that do not conform to AMQP 1.0 Part 1 [e.g. inconsistent size/doff]
2) bytes that while constituting a valid frame (conforms to Part
2.3.1) are an invalid AMQP frame (violates Part 2.3.2) [e.g.
frame-body containing a primitive string rather than performative]
3) bytes that constitute a valid AMQP frame (conforms to Part 2.3.2) but:
3A) performative is malformed [e.g. field with unexpected type or
mandatory with value null]
3B) performative with additional fields [e.g. a Close with additional fields ]
3C) frame that breaks a AMQP business rule [e.g. Open received on
4) state error [e.g. Begin performative received before Open, Attach
on unknown channel number etc]
Numbers 5-6 relate to the top half (i.e. the functions relating to
Connection, Session, etc):
5) illegal parameters to a method call [e.g.
pn_connection_set_container with null container name]
6) illegal state [e.g. pn_connection_open called twice, pn_session
called on unopened connection, pn_session called too many times etc]
When the bottom half encounters input characterised by 1-4, how does
the botton-half of the API behave? What is the effect on the top half?
1. Will the bottom half continue to accept more input?
2. Will the botton-half continue to produce output?
3. How will the application using top half API know an error has
occured? What are the application's responsibilities when it learns of
4. If a connection is already opened, how (if at all) does the
presense of the error condition affect the connection?
When the top half used in a manner characterised by 5-6, how does the
top half behave? What, if any, is the affect on the bottom half?