Open sig-mandel opened 2 months ago
Hey @sig-mandel - so you are suggesting something similar to the Google published client libraries which auto switch the endpoint if you are using experimental models?
... I see in the Google client libraries they default to v1beta
. Perhaps this is better?
ah no, its ok to have to pass the version, but if you try to do so, the library fails because the google api (called from inside this library) doesnt like to receive extra properties.
just to be clear, this library already has a mechanism to change the api version by setting "apiVersion" : "v1beta" in requestOptions, however doing so causes a problem, because that same requestOptions object is passed as-is to the Google API, and the Google api complains that there are extra unexpected properties in the object.
So the fix would be to generate a new, sanitized requestOptions before calling the google api, or to use an extra parameter on this library to set the api version instead of setting it in the requestOptions object (but that requires more code changes)
What you are saying is clear now, however, I don't think requestOptions
make it into the url fetch as the _makeRequest
only passes in params
See https://github.com/mhawksey/GeminiApp/blob/main/src/GeminiApp.js#L51-L54
I've encountered issues in the past when making v1beta
calls without updating the apiVersion
but didn't realise it also extended to what model you used so think defaulting to v1beta
makes sense. I need to do a refresh so will incorporate this in as an enhancement
im not sure if its just a matter of the default. I get your point about the requestOptions not getting passed straight, but it does get passed indirectly: makerequest is called by generateContent, called by sendMessage. In there, see this line, where it sets generateContentRequest (called "params" in that called function) including the apiVersion that could be there.
Its easy to reproduce it you use a config like this one in the call: const generationConfig = { "temperature": 0, "top_p": 0.95, "top_k": 64, "maxOutputTokens": 8192, "apiVersion": "v1beta" }
Ah - I think it's not clearly documented about where apiVersion
is added, it's an additional parameter outside of the generationConfig
.
const generationConfig = {
stopSequences: ["red"],
maxOutputTokens: 200,
temperature: 0.9,
topP: 0.1,
topK: 16,
};
const model = genAI.getGenerativeModel({ model: "gemini-1.5-pro-exp-0801", generationConfig }, { apiVersion: 'v1beta' });
aha! my issue was I was using the library wrong, sorry :( I was passing generationConfig in there instead of requestOptions, and thats why it was picking the version from there but later failing
When I tried to use that version of the model, the library returns an error about not finding the model. In the library I see the default version is "v1" and I found that changing it to "v1beta" makes it work.
However, if instead of modifying the library I try to use the library mechanism of adding
"apiVersion" : "v1beta"
to requestOptions, it does pick up that version inconst apiVersion = this.requestOptions?.apiVersion || DEFAULT_API_VERSION;
but later the API call fails with: Request to Gemini failed with response code 400 - { "error": { "code": 400, "message": "Invalid JSON payload received. Unknown name \"apiVersion\" at 'generation_config': Cannot find field.", "status": "INVALID_ARGUMENT",...