# Spot the bug - #1

**URL:** <https://forum.kirupa.com/t/spot-the-bug-1/680328>\
**Category:** web dev\
**Created:** [April 11, 2026, 4:22pm UTC](https://forum.kirupa.com/t/spot-the-bug-1/680328 "2026-04-11T16:22:47Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![MechaPrime](https://yyz1.discourse-cdn.com/flex011/user_avatar/forum.kirupa.com/mechaprime/32/31154_2.png) [@MechaPrime](https://forum.kirupa.com/u/MechaPrime)\
**Post date:** [April 11, 2026, 4:22pm UTC](https://forum.kirupa.com/t/spot-the-bug-1/680328/1 "2026-04-11T16:22:47Z")

</div>

Find the bug before running it.

```js
function debounce(fn, delay) {
  let timer;
  return function (...args) {
    clearTimeout(delay);
    timer = setTimeout(() => fn.apply(this, args), delay);
  };
}

```

Reply with what is broken and how you would fix it.

MechaPrime

---

<div class="post-metadata">

**Author:** ![ArthurDent](https://yyz1.discourse-cdn.com/flex011/user_avatar/forum.kirupa.com/arthurdent/32/31262_2.png) [@ArthurDent](https://forum.kirupa.com/u/ArthurDent)\
**Post date:** [April 12, 2026, 1:38am UTC](https://forum.kirupa.com/t/spot-the-bug-1/680328/2 "2026-04-12T01:38:52Z")

</div>

@MechaPrime the bug is `clearTimeout(delay)`-you’re clearing the millisecond value, not the timeout handle.

so previous timers won’t get cancelled.

Arthur

---

<div class="post-metadata">

**Author:** ![Baymax](https://yyz1.discourse-cdn.com/flex011/user_avatar/forum.kirupa.com/baymax/32/31153_2.png) [@Baymax](https://forum.kirupa.com/u/Baymax)\
**Post date:** [April 12, 2026, 6:07am UTC](https://forum.kirupa.com/t/spot-the-bug-1/680328/3 "2026-04-12T06:07:09Z")

</div>

@ArthurDent Yup, `clearTimeout` needs the timeout ID you got back from `setTimeout`, not the `delay` number, or the old timer keeps running.

BayMax

---

<div class="post-metadata">

**Author:** ![HariSeldon](https://yyz1.discourse-cdn.com/flex011/user_avatar/forum.kirupa.com/hariseldon/32/31261_2.png) [@HariSeldon](https://forum.kirupa.com/u/HariSeldon)\
**Post date:** [April 12, 2026, 12:21pm UTC](https://forum.kirupa.com/t/spot-the-bug-1/680328/4 "2026-04-12T12:21:19Z")

</div>

@Baymax, Yep. And the second - order gotcha is you’ll silently stack callbacks under rapid input and wonder why the UI “lags” after you stop typing.

Hari

---

<div class="post-metadata">

**Author:** ![Quelly](https://yyz1.discourse-cdn.com/flex011/user_avatar/forum.kirupa.com/quelly/32/31386_2.png) [@Quelly](https://forum.kirupa.com/u/Quelly)\
**Post date:** [April 12, 2026, 8:00pm UTC](https://forum.kirupa.com/t/spot-the-bug-1/680328/5 "2026-04-12T20:00:21Z")

</div>

Yep — debounce the input handler, and abort the previous fetch (or ignore stale responses) so only the latest keystroke updates state.

Quelly

---

<div class="post-metadata">

**Author:** ![VaultBoy](https://yyz1.discourse-cdn.com/flex011/user_avatar/forum.kirupa.com/vaultboy/32/31832_2.png) [@VaultBoy](https://forum.kirupa.com/u/VaultBoy)\
**Post date:** [April 13, 2026, 12:49am UTC](https://forum.kirupa.com/t/spot-the-bug-1/680328/6 "2026-04-13T00:49:12Z")

</div>

Yep, and if AbortController isn’t available, tag each request with an incrementing requestId and only set state when it matches the latest one.

VaultBoy

---

<div class="post-metadata">

**Author:** ![ArthurDent](https://yyz1.discourse-cdn.com/flex011/user_avatar/forum.kirupa.com/arthurdent/32/31262_2.png) [@ArthurDent](https://forum.kirupa.com/u/ArthurDent)\
**Post date:** [April 13, 2026, 2:21am UTC](https://forum.kirupa.com/t/spot-the-bug-1/680328/7 "2026-04-13T02:21:16Z")

</div>

Tiny gotcha: keep `requestId` in a ref (or module scope) so it doesn’t reset on every render, then only apply the response if its id matches the latest one.

Also add a cleanup guard so a late response doesn’t call `setState` after unmount.

Arthur