Dynniq EC-2 responds incorrectly to invalid status requests

[emiltin]

It should respond wirth NotAck, but instead returns a StatusResponse with "q" : "undefined".

Traffic Light Controller Unknown Statuses responds with NotAck to invalid status request name
  Ready
    2021-07-02T13:35:26.460Z 3884     KK+AG9998=001TC000       Requesting non-existing status S0001 name
    2021-07-02T13:35:26.461Z 3884     KK+AG9998=001TC000 564b  Sent StatusRequest {"mType":"rSMsg","type":"StatusRequest","ntsOId":"","xNId":"","cId":"KK+AG9998=001TC000","sS":[{"sCI":"S0001","n":"bad"}],"mId":"564b6b3d-5b2a-4436-a489-fc4192ce270f"}
    2021-07-02T13:35:26.660Z 3884     KK+AG9998=001TC000       Received MessageAck for StatusRequest 564b {"mType" : "rSMsg","type" : "MessageAck","oMId" : "564b6b3d-5b2a-4436-a489-fc4192ce270f"}
    2021-07-02T13:35:29.818Z 3884     KK+AG9998=001TC000 e201  Received invalid StatusResponse, schema errors: /sS/0/n, enum, {"mType" : "rSMsg","type" : "StatusResponse","mId" : "e20131d3-2ac6-4be9-8300-068911afaad8","ntsOId" : "","xNId" : "","cId" : "KK+AG9998=001TC000","sTs" : "2021-07-02T13:31:10.089Z","sS" : [{"sCI" : "S0001","n" : "bad","s" : "","q" : "undefined"}]}

(unfortunately, github does not support colors in issues like here)

[otterdahl]

Yes, but ”undefined” were added in recent versions of the rsmp. Older versions may use NotAck instead. Perhaps Dynniq is implementering an older version? (3.1.2 I think?)

[emiltin]

the core changelog for 3.1.3:

If an object is not known during status request or command request, the site must not disconnect but instead reply with "ageState" set to "undefined"

that seems to imply that you should not send a NotAck?

[otterdahl]

that seems to imply that you should not send a NotAck?

Well, technically the text says "if an object is not known". Object refers to a specific component (cId) and not to the other parts of the message. But, yes. In that case it should not send a NotAck. This error would suggest there is something wrong with the TLC RSMP configuration and not that there is wrong with the JSON format.

But I see that the test case sets "n" to an invalid value, and in this case the TLC should respond with NotAck.

[emiltin]

To be clear. the test is called "responds with NotAck to invalid status request name" because it sends a status request with set n to an invalid value, and expects the site to respond with a NotAck.

Is that expectation correct - should the site respond with NotAck?

[emiltin]

ping @otterdahl

[otterdahl]

The expectation is correct if the RSMP version is 3.1.2 or earlier.

If it uses any later version it should not respond with NotAck, but use q="undefined" instead.

[emiltin]

ok we should create two version of the tests then and add the appropriate rsmp core tags

[emiltin]

If it uses any later version it should not respond with NotAck, but use q="undefined" instead.

this complicates schema validation. the valid status names are listed in an enum in the sxl schema. the above implies that the core version affect how the sxl schema should do it's validation: if core is 3.1.3 or later, the sxl schema should allow any value for the n attribute in status requests.