Odd choice of returned units from orderbookCallBuilder.call() in stellar-sdk

[ire-and-curses]

If I do

const buying = new Asset(code, issuer);
const selling = Asset.native();
const orderbookCallBuilder = server.orderbook(buying, selling);
const orders = await orderbookCallBuilder.limit(2).call();

Then I get something like this:

{ bids:
   [ { price_r: [Object], price: '0.0460110', amount: '307.6952943' },
     { price_r: [Object], price: '0.0460010', amount: '298.2101243' } ],
  asks:
   [ { price_r: [Object], price: '0.0564900', amount: '2321.8474106' },
     { price_r: [Object], price: '0.0565000', amount: '1824.6445497' } ],
  base:
   { asset_type: 'credit_alphanum4',
     asset_code: 'ABDT',
     asset_issuer: 'GDZURZR6RZKIQVOWZFWPVAUBMLLBQGXP2K5E5G7PEOV75IYPDFA36WK4' },
  counter: { asset_type: 'native' } }

I'd like to use XLM units for everything. However, it looks like
• price is in XLM for bids
• amount is amount of XLM for bids
• price is in XLM for asks
• amount is amount of ABDT for asks?!

I can work around this with something like

export function fixHorizonBaseAmount(asks: any) {
  asks = asks.map((a: any) => ({
    ...a,
    amount: Big(a.amount)
      .mul(a.price)
      .toString(),
  }));

  return asks;
}

but the original returns are surprising, and not documented, AFAIK.

[2opremio]

@ire-and-curses should we move this to the javascript repo?

[leighmcculloch]

I think this issue is to do with the data returned from Horizon and not the SDK. As noted in the linked issue above #1193 (comment) this is also something users of the Go SDK has to deal with.

[ire-and-curses]

Yeah I phrased the repro in terms of the JS SDK, but this is actually a problem with the representation in Horizon.

[lmorgan824]

I see this is still an open issue as of today. When working with the testnet orderbook, I am still seeing the bids amount and the asks amount in different units. If we speak of amount as how many times one could execute 1 unit, (i.e. size in equity world) and depth as the total available to be executed at that price, then currently, the bids amount is representing "depth" and asks amount is amount. IMHO the bids amount needs to be fixed to not be depth but amount that could be executed at the price. Based on what I'm seeing on StellarTerm/testnet, they've fixed this internally which leads me to believe that this would be a "breaking" change if made as people have hacked around it already. To fix or not to fix....

[lmorgan824]

My JS hack looks like this currently. (I know my JS looks like C, I'm old school... ;) )
const ob = await sdk.getOrderBook(a1,a2);
for (i = 0; i < ob.bids.length; i++) {
ob.bids[i].amount = (parseFloat(ob.bids[i].amount) / parseFloat(ob.bids[i].price)).toFixed(7);
}

ob now looks like an order book most would expect.