- Expédié
- 19 août 2026 à 02:18 UTC
- Auteur
- kamo
- Commite
- 1eac2a8
Les deux filtres du marché étaient morts, de différentes manières, et ni l'un ni l'autre ne l'a dit. Leads: un onglet de marché correspond à un exemple de plomb, soit par les produits du marché, soit par les produits du marché. La seconde moitié a couru parseInt() sur lead.vendorProductId -- a UUID -- qui revient Quel que soit le chiffre d'avance avec lequel l'UUID commence, donc "3f7c1d4e-..." est devenu 3. Que a ensuite été levé dans le fournisseurProductIds, que LeadMarketDTO déclare Liste-Sting spécifiquement pour survivre à JavaScript, avec le commentaire le dit. Un entier ne correspond jamais une liste de chaînes UUID, de sorte que la branche ne pouvait pas rendre true et un tabulation du marché silencieusement a laissé tomber chaque plomb qui lui appartient par produit vendeur plutôt que par MarketId. Commerce: un marché du commerce est également une chaîne UUID (MarketSummary.id, CommerceMarket.id), et posApi dactylographié marketId en 22 endroits, de sorte que les onglets de pipeline et d'abonnement Numéro(selectedMarketId) -- NaN. Le NaN est falsif, donc le zmarketId ? Garde à l'intérieur chaque appel posApi a abandonné le paramètre de requête et la liste est revenue complètement non filtrée. Choisir un marché semblait fonctionner et n'a rien changé. Les deux sont maintenant comparés et passés sous forme de cordes. Ni l'un ni l'autre n'a été pris par le balayage int64 avant it: ces ids sont UUID, pas arrondis int64s, donc aucune précision n'a été perdue -- la valeur était simplement le mauvais type d'un côté d'une comparaison.