[Reserved-Assets]: Sending reserved-assets updates to frontend

[akspi]

This is bad. The first thing to do for next year is to undo whatever this issue asks you to. Since we now reserve assets prior to execution of requests, all subsequent OrderFillTransactions received to the frontend will only contain partial information. OrderFillTransactions will no longer have details like how much stocks were sold for an AskOrder, how much cash was taken from reserved cash for a BidOrder.

Solution

1. Create a new type of Transaction. Call it ReserveUpdateTransaction
2. These transactions WILL NOT be saved in the database. This is to maintain the sum(...) integrity.
3. For an AskOrder being matched, the transaction will have how much stocks were matched.
4. For an BidOrder being matched, the transaction will have how much cash was taken out of reserve.
5. Send this transaction to the frontend.

[thakkarparth007]

Also, Pai is ashamed of himself for doing this to the code.

[nimishagarwal76]

The purpose here for RESERVE_UPDATE_TRANSACTION is to modify 2 new variables introduced - reservedCash and reservedStocks, since the structure of the transaction was not changed, it required a hack ie. the update transaction.

To remove this -
we can change the structure of transaction -
transaction( id, userId, stockId, type, reservedStockQuantity, stockQuantity, price, reservedCashTotal, total, createdAt)

FromExchangeTransaction
transaction( id, userId, stockId, FromExchangeTransaction, 0, 5,100, 0, -500, createdAt)

ASK FOR 5 stocks by user 1

USER 1
transaction( id, 1, stockId, PlaceOrderTransaction, 5, -5, 0, 0, 0, createdAt)
transaction( id, 1, stockId, OrderFeeTransaction, 0, 0, 0, 0, -210, createdAt)
USER 2
transaction( id, 2, stockId, PlaceOrderTransaction, 0, 0, 0, 1000, -1000, createdAt)
transaction( id, 2, stockId, OrderFeeTransaction, 0, 0, 0, 0, -210, createdAt)

AFTER STOCK GETS MATCHED

// say it gets matched for 4 stocks at 250 rs
transaction( id, 1, stockId, OrderFillTransaction, -4, 0, 250, 0, 1000, createdAt)

transaction( id, 2, stockId, OrderFillTransaction, 0, 4, 250, -1000,0, createdAt)

@PaiAkshay998 @Harsh2098 your views on this approach

[akspi]

I'm not entirely sure if this is the best way to go. Feel like our current transaction is able to handle / contains all the necessary information about each type of transaction. However, the reserve stock changes had a few issues with us manually resetting values of Ask Order fill transaction or something of that sort which has been discussed in greater detail in #289. The issue deals with not having to do that which requires some fundamental change in how our matching engine works.

[nimishagarwal76]

Our current transaction is able to handle / contains all the necessary information about each type of transaction It does not contain information about how many stocks are Sold in case of Ask order. So a user can not map his transactions. Even we send a hidden transaction to manipulate the UI, so I think having all the variables in display in the transaction will increase transparency. Last time even we had difficulty explaining people their transaction as we ourselves did not have information regarding how many stocks were sold (As we didn't store reserve_update in db).
Similar is the case for Bid Order.
With the current model, a user can't map the stocks and reserved cash from start ig.

[nimishagarwal76]

And also there would be one more advantage, uniformity in the way we handle transactions in Main.tsx, we won't require a switch, just add to the corresponding variable irrespective of transactions.