faragom
commented
4 years ago Hi,
Application flow errors at the RM should be managed by issuing a response without attributes and an error state inside (Raquel and Myriam can tell you, it was done this way in ESMO). Completely unexpected errors like the SM communication issue you describe, don't need to be handled. It's enough to return an HTTP error response, and the application flow will stop there. I mean, the user will see the error right on his face, and it is useless to do a more complex management of errors that should not happen and that completely break the functionality of the service.
El lun., 15 jun. 2020 a las 13:57, cbuendia-atos (notifications@github.com) escribió:
Hello, @faragom https://github.com/faragom
In rm/request there are error responses which are defined on interface-specs.
However when a request is received on this endpoint, we don't know how to make sure the SP gets noticed about the error.
For example, in case the RM had an error when communicating with the SM, how is the RM supposed to be handling the errror, and communicating back to the SP?
Thanks in advance
cc'd @EC-SEAL/atos https://github.com/orgs/EC-SEAL/teams/atos
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/EC-SEAL/request-manager/issues/7, or unsubscribe https://github.com/notifications/unsubscribe-auth/AG4HJ6YLL4BAMTXVXDSKUO3RWYEBDANCNFSM4N6DJZ3A .
-- Francisco José Aragó Monzonís mitsurugisan@gmail.com
cbuendia-atos
Hello, @faragom
In
rm/requestthere are error responses which are defined on interface-specs.However when a request is received on this endpoint, we don't know how to make sure the SP gets noticed about the error.
For example, in case the RM had an error when communicating with the SM, how is the RM supposed to be handling the errror, and communicating back to the SP?
Thanks in advance
cc'd @EC-SEAL/atos