fix(amazonq): debounce inline suggestion requests.

[Hweinstock]

Problem

When typing a decent amount of text in quick succession, the language server will get throttled in its requests to the backend. This is because we send a request for recommendations on every key stroke, causing the language server to make a request on each key stroke. This is rightfully getting throttled by the backend.

Solution

• The ideal behavior is that we only make a request to the language server, and thus to the backend, when typing stops. Therefore, this is an ideal use case for debounce. However, we need to extend debounce slightly outlined below.
• Apply debounce to the recommendations such that we wait 20 ms after typing stops before fetching the results.
• By applying this at the recommendation level, none of the inline latency metrics are affected.

Debounce Changes

-Let f be some debounced function that takes a string argument, our current debounce does the following:

f('a') f('ab') f('abc') (pause for debounce delay) -> f would be called with 'a'

The issue is is that for suggestions, this means the language server request will be made with stale context (i.e. not including our most recent content). What we want instead is for the case above to call f with 'abc' and not with 'a' or 'ab'.

We can accomplish this by adding a flag to debounce allowing us to choose whether we call it with the first args of the debounce interval (default, and 'a' in the example above), or the most recent args ('abc' in the example above).

Verification

• I did not notice the added latency when testing inline. However it does seem slower than prod, with and without this change.
• I was not able to get a throttling exception.

---

• Treat all work as PUBLIC. Private feature/x branches will not be squash-merged at release time.
• Your code changes must meet the guidelines in CONTRIBUTING.md.
• License: I confirm that my contribution is made under the terms of the Apache 2.0 license.

[Hweinstock]

didn't see these used anymore, so I deleted for clarity.

[jpinkney-aws]

these were probably missed when I was deleting code. One of the problems with exporting in typescript is that it makes it very hard to detect which exports are actually used

[jpinkney-aws]

these were probably missed when I was deleting code. One of the problems with exporting in typescript is that it makes it very hard to detect which exports are actually used

[Hweinstock]

Could we use something like https://www.npmjs.com/package/ts-unused-exports? I just ran it and got 951 results, so this might be noisy. Perhaps something to investigate in the future if more bandwidth is available.