search

erasmus-without-paper / ewp-specs-api-omobility-las

Learning Agreements
MIT License
1 stars 2 forks source link

New error code for already approved/rejected error #51

Open lsanchezpe opened 2 days ago

lsanchezpe commented 2 days ago

A specific problem we've found in accept or reject of LAs is the following situation:

  1. We receive a LA with some changes proposal
  2. Se send acceptance/rejection to the partner but for some misconfiguration (or may be other reasons) we go through a read timeout error. So as it was a read timeout error we didn't receive a 200 response but they answer with a 200 code (which we withdrawn due to the read timeout error). Considering this we didn't change the status, but in the partner side does.
  3. When we retry the acction (as we didn't receive a 200 response) we receive an error saying this proposal is already accepted/rejected.

As I see the problem is that we have to go to the message to know this case is applyin and of course it may differ from one provider to other,

Can we standarize a error code to return in order to identify this scenario?

The most acurate specification about this i've found is this handling edit conflicts but its more focused in edition conflicts and changes proposals no longer availables.

As some partners suggested, I can perform a get LA before send the acceptance/rejection of this LA, but this scenario can sill happend. Of course i have a workarroud to mark it as accepted/rejected manually bassed on the error message but if we can standarize a error code to this specific situation it can be automated.

m-sokolowski commented 1 day ago

If the partner received your approval/rejection, then according to the specification, they should send you a notification about the new version:

Please note, that the sending institution SHOULD send this notification to you even when it is you who actually initiated the update (e.g. via the update endpoint of Outgoing Mobility Learning Agreements API).

So when such a timeout occurs, you should receive a CNR and have the newly approved version with all signatures in your system. Is that not enough for your users? Or is this specific partner not sending CNRs in this case (which is an error described also in the EWP Developers Guide)?

I agree that a new error code would help to identify such scenarios, but I'm still not sure if this is necessary.

lsanchezpe commented 1 day ago

In some cases the partner didn't send this CNR and in the other hand our system don't take in consideration this scenario so we have the LA in the correct state but our approval/rejection continue retrying and thats not correct.

Even though we correct this behaviour, some other scenarios can appear that goes to this situation and i find usefull and easy to implement the error code i'm talking about.

I wish other providers give their oppinions about that