Do not warn for requests aborted by the caller
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 86/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- typescript
- Domain
- api
Research direction
Start in src/Typesense/ApiCall.ts, focusing on ApiCall.performRequest() and its catch block. Reproduce the abortSignal search scenario, then verify that caller-initiated aborts reject as "Request aborted by caller." without a warning, while network failures and other request errors still warn.
Written by the indexing model from the issue text.
Description
Description
When a caller aborts an in-flight request using abortSignal, ApiCall emits a warning such as:
Request #…: Request to Node 0 failed due to "ERR_CANCELED canceled"
The request then rejects with Request aborted by caller., as expected. A caller-initiated abort is routine when replacing an in-flight search (for example, while someone types), so this warning adds noise to browser logs.
Steps to reproduce
- Create a
SearchClientand start a search against a server that keeps the request pending. - Pass an
AbortControllersignal as the search option:client.collections('example').documents().search({ q: '*' }, { abortSignal: controller.signal }). - After the server receives the request, call
controller.abort().
Expected behavior
The search rejects as aborted, without logging a failure warning. Network failures and other genuine request errors should still warn.
Actual behavior
ApiCall.performRequest() sets wasAborted when the signal fires, but its catch block calls logger.warn(...) before checking wasAborted and returning Request aborted by caller.. Could the warning be skipped when wasAborted is true?
This occurs with typesense-js 2.1.0 and the same logging order appears in 3.1.0:
- Dominant language
- TypeScript
- Stars
- 572
- Forks
- 101
- Avg merge
- 12h 10m
- Merged PRs (30d)
- 4
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from typesense/typesense-js
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
typesense/typesense-js#372 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
typesense/typesense-js#369 ·
-
Typing for geo_distance_meters is too strictMay be free again A pull request for this issue was closed without being merged. Open
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
typesense/typesense-js#348 ·
-
Get rid of AxiosOpen
Difficulty 5/5 Over a week Newbie friendliness 35/100
typesense/typesense-js#380 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 25/100
typesense/typesense-js#324 · 1 comment ·
All issues in typesense/typesense-js
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
simkimsia/netlify-axi#19 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
subhranshudash13-dotcom/Contribo#74 ·
Maintainers usually reply within 1 day
-
enhancement frontend good first issue Stellar Wave trivial
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Godgift-care/sci-healthcare-frontend#166 · 1 comment ·
Maintainers usually reply within 1 day
-
backend good first issue security Stellar Wave trivial
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Godgift-care/sci-healthcare-backend#171 · 1 comment ·
Maintainers usually reply within 1 day