Different stocks with different stock addresses can end up with the same id in their StockInfo struct.
In createOffer() - offerId storage variable that keeps track of the last offer id - is incremented BEFORE being stored on OfferInfo({}) and StockInfo({}) structs as the id of those structs.
In createTaker() - offerId is incremented AFTER being stored as the id of StockInfo({}).
Hence, stocks with different stock addresses (because they are generated with different offerIds) can end up with the same id inside their structs.
Ids by definition should be unique. This can cause impact off-chain (frontend & backend) of the system rather than on the contract.
We did not detect impact of this vulnerability on the on-chain system.
Still, we believe it constitutes enough for a valid medium because of the implications.
manual review
Increment offerId variable before stock id assignment in createTaker().
I believe this is valid low severity, although there is inconsistency here when using the correct `offerId` for assigning offerIds and generating the unique addresses as seen [here](https://github.com/Cyfrin/2024-08-tadle/blob/04fd8634701697184a3f3a5558b41c109866e5f8/src/core/PreMarkets.sol#L67-L69), this is purely an accounting error for offerIds. If we generate the offerId using current `offerId - 1`, the appropriate listing/taker orders can still be created against those offers.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.