mirror of
https://github.com/duckietm/Nitro-V3.git
synced 2026-06-19 23:16:21 +00:00
simoleo89
a9515cb1a0
ModToolsChatlogView and CfhChatlogView were on the useNitroQuery pattern. Symptom: the card opens, the spinner spins, but the data never arrives — even when the server is correctly answering with ModToolRoomChatlogComposer (header 3434) and GetCfhChatlogComposer (607). Both header IDs match the renderer's Incoming map, both server handlers gate only on ACC_SUPPORTTOOL and reply unconditionally when the room/issue lookup succeeds. So the request DOES go out and the response DOES come back — but useNitroQuery's listener (registered via `new (ParserCtor)(callback)` + `registerMessageEvent`) isn't delivering the event to the React side here. ModToolsUserChatlogView already uses the plain `useMessageEvent` + `useEffect(sendComposer)` pattern and works on this same setup, so align the two broken views with it. Keep the loading-spinner empty state introduced yesterday so the user still gets visible feedback while the response is in flight. This sidesteps useNitroQuery for these two cases rather than fixing it in place — the underlying createNitroQuery + listener registration plumbing still works for OfferView, useUserGroups, useClubOffers, useSellablePetPalette, useMarketplaceConfiguration, useClubGifts, CatalogLayoutRoomAdsView, so the regression is specific to these two parsers and worth investigating separately. Filed as a follow-up.