-
Notifications
You must be signed in to change notification settings - Fork 283
Conversation
Looks good at first glance. I'll take a deeper look and test it later today. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is fine as a quick solution. Before this is merged, I'd like to ensure theres:
- unit test protecting the success case
- unit test protecting
walkpath
's failure handling - unit test protecting
updater
's failure handling - updating the postman docs for this new endpoint
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should also suspend the root hash updater while this bulk update is completing. Otherwise, each individual listing update will trigger the root hash to be updated in the push nodes and create a lot of network chatter. The root hash could be resumed after the bulk update and the final merkle root could be enough to cover all the changes.
It looks like this branch set all the listings to track inventory, zero inventory on 2 of my nodes. I'll try and confirm that. |
I've verified that calling bulkupdatecurrency will set all of your listings' skus to have a quantity of zero instead of whatever they had before, which sets them to track inventory with an inventory of 0, making them unbuyable. If they have a coupon, it also removes the This is a fairly serious bug, in my opinion. |
The reason this bug occurs is that we perform this bulk update incorrectly. The way it currently works is:
This causes a problem because what's on disk is not what actually should get sent to the API. It's missing inventory and coupon information. I will go ahead and update this code to perform this properly. |
Ok @jjeffryes it looks like this is now considering the inventory and coupons. It wasn't as bad as I thought it would be. @placer14 we need a double check to make sure we're not doing anything else wrong here as we completely overlooked that it wasn't putting the coupons and inventory in there. |
This seems to be working as intended now. |
Great. I just need to apply the other fixes @placer14 suggested. |
This latest commit should defer the publish until everything is completed. |
@jjeffryes ready for testing again with updates. @placer14 what else is needed here? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some thoughts on how to approach the testing.
core/moderation.go
Outdated
return err | ||
} | ||
|
||
n.SeedNode() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This returns an error that needs to be checked and handled.
core/moderation.go
Outdated
|
||
} | ||
return nil | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking over the code again, my biggest concern is the amount of behavior we have inside of walkpath
that is not verified. (https://github.com/OpenBazaar/openbazaar-go/pull/1423/files#diff-3ef083f7462052e03c5b8d5fed226805R188) The API test verifies the response, but doesn't look at the data to make sure the walkpath functionality worked properly. And it touches a bunch of points.
Two ways to solve this:
The harder (but preferred) of the ways to solve this would be pulling out each piece of behavior and unit testing the individual behavior. Then you can call the methods and be confident they are doing the right thing. You wouldn't need to test in the API layer and could have tighter tests around each specific behavior by itself. Bonus points if you walk through the code and replace other matching uses with your extracted/tested version.
The other easier way to solve this (though costs more in the longterm) would be by crafting a listing which exercises all of these features. A proper exercise would ensure:
sl.Listing.Metadata.AcceptedCurrencies = currencies
was changed to a new value from an old different value- that coupons were properly reapplied to the listing
- that
shippingService.AdditionalItemPrice
is set properly on legacy listings (how did you know to check this?) - that inventory is properly reapplied to the listing
If you could craft such a perfect listing, you could simply do a GET /listing and ensure the above items match. (you might need to do more with inventory checking...)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A magic listing test runs the risk of not creating the example to sufficiently catch any regressions which may happen later (an impossible task). Another reason the unit tests would be preferred, as regressions in one part wouldn't necessarily be hard to fix across the codebase once it occurs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok I believe the 100% coverage on this stuff should cover your requests.
Skeleton for signed listings tests Unit tests for signed listings [1] Additional unit tests signed listings
4dc7753
to
6158289
Compare
Ready for review @placer14 |
GTG @cpacia |
This is a very similar API call to the one used to update moderators for all listings.
POST http://localhost:4002/ob/bulkupdatecurrency
Payload: { "currencies":["ZEC", "BTC", "BCH", "LTC"] }
This will update the listings.json as well as ALL listings themselves with the updated currency array.