Skip to content

M2.1.2 : Shipment Tracking REST API should throw an error if order doesn't exist. #7760

Closed
@kanduvisla

Description

@kanduvisla

When you add a tracking code using the REST API, Magento doesn't throw an error if you try to add a tracking code for a non-existing order. Take the following example:

{
	"entity": {
		"order_id": 20,
		"parent_id": 12,
		"track_number": "string",
    	"title": "string",
    	"carrier_code": "custom"
	}
}

In the above example, there is no order with ID '20' in my database. However, I have an order with id '19' that has a shipment with ID '12'. So posting the above to the REST API will not throw an error. Instead it will return something similar to this:

{
  "order_id": 20,
  "created_at": "2016-12-12 13:37:57",
  "entity_id": 12,
  "parent_id": 12,
  "updated_at": "2016-12-12 13:37:57",
  "weight": null,
  "qty": null,
  "description": null,
  "track_number": "string",
  "title": "string",
  "carrier_code": "custom"
}

I came across this 'feature' when a 3rd party was trying to add tracking codes to the Magento 2 API, but they accidentally used the increment ID instead of the order ID

Preconditions

  1. Magento 2.1.2

Steps to reproduce

  1. Create some orders where the increment ID is not equal to the order ID (not necessarily, but it illustrates the problem).
  2. Give on of the orders a shipment so you have a valid shipment ID voor the parent_id in the request.
  3. Create an API-request with a non-existing order-ID, but the existing shipment ID.

Expected result

  1. I would expect the API to return an error message like 'order not found' or something.

Actual result

  1. It creates the tracking code on to a shipment that does not match to any order (yet).

The big problem with this is as soon as the non-existing order gets created. In that case you have a tracking number that matches with an order and a shipment, but those shipment and order do not match with each other.

This was the case in my scenario, where the shipment tracking code would show up in the 'Comments History' panel, but not on any of the actual shipments that were linked to the order. At the same time, the order that should have the tracking code didn't have the comment, but it had the tracking code in the shipment. But this was more because at that moment the increment ID and entity ID of the shipments were the same (inc id #13 was entity id 13).

As soon as increment ID's and entity ID's of orders / and or shipments are not 'the same', using the increment ID in the API would give unexpected results.

I think an extra check on the API could prevent a lot of errors:

  • Check if order_id exists.
  • Check if parent_id is actually a shipment of order_id.

Metadata

Metadata

Assignees

Labels

Component: Framework/WebapiUSE ONLY for FRAMEWORK RELATED BUG! E.g If bug related to Catalog WEB API use just CatalogFixed in 2.2.xThe issue has been fixed in 2.2 release lineIssue: Clear DescriptionGate 2 Passed. Manual verification of the issue description passedIssue: ConfirmedGate 3 Passed. Manual verification of the issue completed. Issue is confirmedIssue: Format is validGate 1 Passed. Automatic verification of issue format passedIssue: Ready for WorkGate 4. Acknowledged. Issue is added to backlog and ready for developmentReproduced on 2.1.xThe issue has been reproduced on latest 2.1 releaseReproduced on 2.2.xThe issue has been reproduced on latest 2.2 releaseReproduced on 2.3.xThe issue has been reproduced on latest 2.3 releasebug report

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions