- Ya
- 19 Agosti 2026, 02:18 UTC
- Mwandishi
- kamo
- Ahadi ya
- 1eac2a8
Both market filters were dead, in different ways, and neither said so. Leads: a market tab matches a lead either by marketId or by the market's vendor products. The second half ran parseInt() over lead.vendorProductId -- a UUID -- which returns whatever leading digits the UUID happens to start with, so "3f7c1d4e-..." became 3. That was then looked up in vendorProductIds, which LeadMarketDTO declares List<String> specifically to survive JavaScript, with the comment saying so. An integer never matches a list of UUID strings, so the branch could not return true and a market tab silently dropped every lead that belongs to it by vendor product rather than by marketId. Commerce: a commerce market id is a UUID string too (MarketSummary.id, CommerceMarket.id), and posApi typed marketId as number in 22 places, so the pipeline and subscription tabs passed Number(selectedMarketId) -- NaN. NaN is falsy, so the `marketId ? ...` guard inside each posApi call dropped the query parameter and the list came back completely unfiltered. Picking a market appeared to work and changed nothing. Both are now compared and passed as strings. Neither was caught by the int64 sweep before it: these ids are UUIDs, not rounded int64s, so no precision was lost -- the value was simply the wrong type on one side of a comparison.