typescript-eslint no-floating-promises flags every croct.track and croct.identify call
Enabled the strict typescript-eslint preset. Result:
error Promises must be awaited, end with a call to .catch, end with a call to.then with a rejection handler or be explicitly marked as ignored with the`void` operator @typescript-eslint/no-floating-promiseson every croct.track() and croct.identify() in the codebase. Before I blanket-void them: is awaiting these actually required for correctness, or is void the accepted pattern? I am not going to disable the rule, it has caught real bugs. i just want the intended usage.
1 answer
The rule is doing its job, and the right treatment differs by method, so resist the blanket void.
For tracking calls, void is fine in the common case. Delivery is handled by the SDK, so void croct.track('goalCompleted', {goalId: 'signup'}) loses nothing. Await it only when you need delivery ordering, for example tracking right before a hard navigation where you want the promise settled first.
For identify, awaiting is the safer default when subsequent calls depend on the identified state, such as identifying on login and immediately fetching personalized content for that user.
For evaluate and fetch, never swallow them, their results are the whole point and their failures need a defined fallback. The documented patterns:
const returning = await croct.evaluate('user is returning').catch(() => false);
const {content} = await croct.fetch('home-hero@1').catch(() => ({ content: defaultHeroContent,}));That way a timeout or blocked request degrades to default behavior instead of an unhandled rejection. Net effect: your lint rule stays on, tracking gets void, and the value-returning calls get explicit fallbacks, which is exactly the discipline the rule exists to enforce.