- Szycy
- 19 sierpnia 2026 02:18 UTC
- Autor
- kamo
- Pochęt się
- 1eac2a8
Oba filtry rynkowe były martwe, na różne sposoby, i żadne z nich tak nie powiedziało. Leads: zakładka rynkowa pasuje do wiodącej pozycji przez marketId lub przez produkty dostawców rynku. Druga połowa przejechała parseInt() nad lead.vendorProductId - UUID - który powraca Bez względu na to, od których wyróżnia się Większe cyfry UUID, więc "3f7c1d4e-..." stał się 3. To jest Następnie został przeszukany w vendorProductIds, który LeadMarketDTO deklaruje List-String> W szczególności, aby przetrwać JavaScript, z komentarzem tak. Liczba całkowita nigdy nie pasuje Lista ciągów UID, więc gałąź nie mogła zwrócić prawdziwej i zakładki rynku w milczeniu Upuścił każdy trop, który należy do niego przez produkt dostawczy, a nie przez marketId. Handel: acommerce market id jest również ciągiem UUID (MarketSummary.id, CommerceMarket.id), i posApi typted marketId jako liczba w 22 miejscach, więc zakładki rurociągu i subskrypcji Numer (selectedMarketId) - NaN. NaN jest fałszowy, więc ?marketId? ..." strażnik w środku Każda wywołanie posApi upuściła parametr zapytania, a lista wróciła całkowicie niefiltrowana. Wybór rynku wydawał się działać i nic nie zmieniał. Obie są teraz porównywane i przekazywane jako struny. Żaden z nich nie został wcześniej złapany przez int64. To: te identyfikatory są UUID-ami, a nie zaokrąglone int64s, więc żadna precyzja nie została utracona - wartość była Po prostu niewłaściwy typ po jednej stronie porównania.