fix: lp_cancel_orders_batch to accepts OrderId as string/hex

[marcellorigotti]

Pull Request

Closes: PRO-1897

Checklist

Please conduct a thorough self-review before opening the PR.

• I am confident that the code works.
• I have written sufficient tests.
• I have written and tested required migrations.
• I have updated documentation where appropriate.

Summary

Updated the LP-API cancel_orders_batch to accepts OrderId as string/hex as well

Non-Breaking changes

If this PR includes non-breaking changes, select the non-breaking label. On merge, CI will automatically cherry-pick the commit to a PR against the release branch.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 72%. Comparing base (8f4011f) to head (0c3f70f).
Report is 43 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##            main   #5504     +/-   ##
=======================================
- Coverage     72%     72%     -0%     
=======================================
  Files        490     495      +5     
  Lines      86894   88259   +1365     
  Branches   86894   88259   +1365     
=======================================
+ Hits       62395   63169    +774     
- Misses     21565   22521    +956     
+ Partials    2934    2569    -365     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[kylezs]

can remove the mut var by collecting

Suggested change

	let mut final_orders: BoundedVec<CloseOrder, ConstU32<MAX_ORDERS_DELETE>> =
	BoundedVec::new();
	for order in orders {
	final_orders
	.try_push(order.try_into()?)
	.expect("Impossible to fail, given the same MAX_ORDERS_DELETE");
	}
	Ok(self
	.api
	.lp_api()
	.cancel_orders_batch(
	orders
	.into_iter()
	.map(TryInto::try_into)
	.collect::<Result<Vec<_>, _>>()?
	.try_into()
	.expect("Impossible to fail, given the same MAX_ORDERS_DELETE"),
	wait_for.unwrap_or_default(),
	)
	.await?)

[marcellorigotti]

Doesn't this require an extra memory allocation for the Vec<> when collecting?
(or maybe this gets optimized away by the compiler?)

[kylezs]

Yes, I believe so. But given the performance gain is negligible, I think having without a mut var is a bit simpler and less likely to be mistakenly broken with future changes (definitely isn't a strong opinion which way is preferred here)