Closed eggwhat closed 9 months ago
Unfortunately, there is a problem during getting offers by endpoint /parcels/{parcelId}/offers because offer from external api is null. Some error in ExternalApiLecturerService can be observed and it can be associated with getting document as null in query handler related to that endpoint.
Unfortunately, there is a problem during getting offers by endpoint /parcels/{parcelId}/offers because offer from external api is null. Some error in ExternalApiLecturerService can be observed and it can be associated with getting document as null in query handler related to that endpoint.
You are right. It doesn't take into account when MiniCurrier rejects our request. I will push update in a moment. And one important thing. Our backend uses values in following units: "Meters", "Kilograms" and "Pln". The reason why this request was rejected is because parcel was to big and it failed MiniCurrier validation.
I deleted objects with wrong structure and provided a change. Please let me know if you encounter any issues now.
Now, endpoint parcels/{parcelId}/offers works great for some inquiry created by you some time ago, it returns two offers (from SwiftParcel and MiniCurrier), but now I have problem with InquiriesServiceException during creating an inquiry and this exception is thrown by ExternalApiLecturerService. Below there is fragment of code in AddParcelHandler.cs file.
Now, endpoint parcels/{parcelId}/offers works great for some inquiry created by you some time ago, it returns two offers (from SwiftParcel and MiniCurrier), but now I have problem with InquiriesServiceException during creating an inquiry and this exception is thrown by ExternalApiLecturerService. Below there is fragment of code in AddParcelHandler.cs file.
This is probably failed validation on MiniCurrier side -> the parcel dimensions and weight are too big. I will add some validation on our side to not accept such big values. As i said the backend treats this values as in meters and kilograms respectively.
Now, endpoint parcels/{parcelId}/offers works great for some inquiry created by you some time ago, it returns two offers (from SwiftParcel and MiniCurrier), but now I have problem with InquiriesServiceException during creating an inquiry and this exception is thrown by ExternalApiLecturerService. Below there is fragment of code in AddParcelHandler.cs file.
This is probably failed validation on MiniCurrier side -> the parcel dimensions and weight are too big. I will add some validation on our side to not accept such big values. As i said the backend treats this values as in meters and kilograms respectively.
I checked it and proper values for parcel are between: "Length should be between 0.2m and 8m" "Height should be between 0.2m and 8m" "Width should be between 0.2m and 8m" and for weight: "'Weight' must be between 0,1 and 100. You entered 100000."
Thank you @eggwhat for this checks. What do you think, it will be better when user would not be allowed to enter data out of this ranges and always will get offer from two apis, or not to check it and then in the worst case user will get only an offer from our company? If the first case is better option, I will update validation during creating inquiry on the frontend side.
I think the first option is our go-to. I will update our backend validation to always have valid values also for MiniCurrier service.
Also i will add validation for pickup and delivery date, because for MiniCurrier the inquiry has to have pickupDate > current time and deliveryDate > pickupDate
I also found an issue in MiniCurrier Api. Inquiry can have some dimensions equal 8 meters but when all dimensions are equal 8 meters there is error 500. So i will have to make validation <8
Features:
Api guideline will be published soon in a new issue.