-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Raise InsufficientStock if and only if there is insufficient stock #566
Raise InsufficientStock if and only if there is insufficient stock #566
Conversation
👍 I agree with your logic. |
I'm concerned this will break the behavior this commit was trying to correct. I think that if we remove this we need to add a check further down the line that everything in the order can be shipped when generating shipments. |
@richardnuno I don't 100% follow what that check is guarding against. If you could outline what a test would look like that would cover the case you're worried about, I think either Hawth or myself could write it up. |
@cbrunsdon sure! The test would ensure that you cannot transition an order to the delivery state if any of the order's contents couldn't be shipped. |
d834fcb
to
b3fd0b3
Compare
I wrote some specs to demonstrate the behaviour of that check. This asserts that InsufficientStock is raised whenever there isn't enough inventory. Here is the result:
The existing check works in a minority of cases, only when the stock location is fully out of stock. It will silently makes a package with insufficient inventory if there is some, but insufficient stock. This also raises the error incorrectly if one stock location is empty, but the other has sufficient inventory. These new specs also presented another issue: packaging seems to be broken when it need inventory from multiple stock locations to be fulfilled. This is the pending spec here. We probably do want to check for this elsewhere (maybe at the end of package coordination) and raise exceptions. |
b3fd0b3
to
16f7893
Compare
16f7893
to
eb0008d
Compare
@richardnuno does this cover the case you are concerned about? I'm concerned that neither of these changes really broke any tests. I suspect there is not good coverage of the various |
@jhawthorn yes this covers it, thanks! |
eb0008d
to
77c647c
Compare
Rebased against latest master |
77c647c
to
18fce61
Compare
Rebased again and added changelog entry |
de25d2b
to
9705017
Compare
Stock::Packer currently raises InsufficientStock under specific circumstances: * There is a stock item for a variant in the stock location. * There is exactly 0 inventory remaining for that variant in the stock location. * The variant does not allow backordering. This is odd, because it doesn't raise InsufficientStock when there is some but insufficient inventory (it adds the amount available to the package), or if the stock item doesn't exist at all in that stock location. These three cases should probably be handled in the same way. The way the Packer is used is to build the fullest possible package for this stock location. As it's possible to fulfill an variant half from one location and half from another, this method should not be raising InsufficientStock because it has insufficient information to do so.
Instead of raising this inside of the Packer (and only in some cases), raise it any time our final package didn't contain the full requsted quantity.
Since the previous spec having stock locations with insufficient stock failed (and is marked pending) I've added two more examples which do pass.
9705017
to
c1bac98
Compare
Those tests are magnificent. Thanks @jhawthorn, I don't have any objections to the PR, and its definitely moving us in the right direction. If it has any unintended side-effects I can't think of where, but we'll have to deal with them if and when they come up. Also from now on I'm going to use these as a reference for writing clean tests in these types of situations. |
Raise InsufficientStock if and only if there is insufficient stock
Previously,
InsufficientStock
was raised if any StockLocations were fully out of inventory. This was incorrect because it was possible other stock locations could have fulfilled the inventory. This was also incorrect because the stock location could have some, but insufficient inventory, and not raise the exception (an incomplete package would be returned). Now the coordinator checks that the package is complete and raisesInsufficientStock
if it is incomplete for any reason.Stock::Packer currently raises InsufficientStock under specific circumstances:
This is odd, because it doesn't raise
InsufficientStock
when there is some but insufficient inventory (it adds the amount available to the package), or if the stock item doesn't exist at all in that stock location. These three cases should probably be handled in the same way.The way the Packer is used is to build the fullest possible package for this stock location. As it's possible to fulfill an variant half from one location and half from another, this method should never raise
InsufficientStock
because it has insufficient information to do so.