Skip to content
This repository has been archived by the owner on Oct 10, 2024. It is now read-only.

feat: add signal support and fix timeout, closes #5 #68

Conversation

sublimator
Copy link
Contributor

@sublimator sublimator commented May 1, 2024

  1. Added a new function combineSignals in src/client.js to merge AbortSignal instances.
  2. Updated the _request method in src/client.js to accept an additional argument signal and use the combineSignals function to merge with a default timeout signal.
  3. Refactored the chat and chatStream methods in src/client.js to use a single object data for the main chat configuration and an additional options object options, where the signal is passed.
  4. Updated the build and publish workflow to include Node.js version 22 in the matrix (closes Add Node 22 to CI #71 )

src/client.js Outdated
@@ -82,7 +83,7 @@ class MistralClient {
'Authorization': `Bearer ${this.apiKey}`,
},
body: method !== 'get' ? JSON.stringify(request) : null,
timeout: this.timeout * 1000,
signal: signal ?? AbortSignal.timeout(this.timeout * 1000),
Copy link
Contributor Author

@sublimator sublimator May 2, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Due to the limitations of what's possible when attempting to merge a user provided signal and a timeout signal, this simple approach may be the best that can be done without passing in an AbortController and implementing a timeout that calls its abort method. Thus if the user provides a signal, they are responsible for managing timeouts as well. This would be non-obvious to most users though. On the flip side, passing around an AbortController seems non-standard.

We could document the parameter with something along these lines:
"Users must manage timeouts for their own AbortSignals. Without a user-provided signal, a default timeout of [x] seconds applies automatically."

Copy link
Contributor Author

@sublimator sublimator May 2, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, that may not be the case re: merging, as the signal.reason /is/ available and should be possible to transfer to a new merged signal

(
LLM: says no,
ME: waiiiit, didn't I check the reason in a catch block ..."
)

@sublimator sublimator marked this pull request as ready for review May 3, 2024 11:14
@sublimator
Copy link
Contributor Author

sublimator commented May 3, 2024

@lerela @fuegoio

When you get a chance?

Thx

Copy link
Contributor

@fuegoio fuegoio left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 👍

@sublimator
Copy link
Contributor Author

@lerela

Let's go!

src/client.js Outdated
@@ -221,6 +246,8 @@ class MistralClient {
* @param {*} safePrompt whether to use safe mode, e.g. true
* @param {*} toolChoice the tool to use, e.g. 'auto'
* @param {*} responseFormat the format of the response, e.g. 'json_format'
* @param {*} [signal] - optional AbortSignal instance to control request
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, it might be worth considering whether to move signal into a second object param, and keep it out of the bag of data that is sent to the server. It's a bit cleaner that way.

On a related note, I realised that the JSDoc comments are actually incorrect (see)

@lerela lerela merged commit 7b55eaa into mistralai:main May 6, 2024
4 checks passed
@fuegoio fuegoio mentioned this pull request May 8, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add Node 22 to CI
3 participants