- Notifications
You must be signed in to change notification settings - Fork 57
[Feature] Added per-call headers capabilities to OpenAiClient #25
[Feature] Added per-call headers capabilities to OpenAiClient #25
Conversation
| There was 1 test that failed due to to a strange issue where the weather unit is described as |
| @singularity-sg sorry, but this PR is very hard to review. Please revert all the changed that only do re-formatting |
b172a7a to e42f8aa Compare
Apologies for that - I think the formatting by the IDE caused the differences due to our differing formatting rules. I've only included the required changes now |
e42f8aa to bc207e7 Compare | Hi @langchain4j could you help me review this PR when you are available 🙏🏼 |
| Hi @singularity-sg I am trying to review everything in the order of priority, I have too much PRs to review now. Thanks a lot for patience and understanding! |
No worries! I appreciate your time in this 🙏🏼 |
| Hi @langchain4j , Sorry for sounding pushy but it'll help with our integration with |
| @singularity-sg do you plan to make a similar change in langchain4j? |
|
| No, I mean the alignment with the current lc4j api. There is now no way to define parameters per request now. Although there is a plan to make ChatLanguageModel API more flexible (e.g. to set parameters per request), it is not there yet. |
I see what you mean. I've not made any modifications to the existing API contracts (just adding more method for flexibility). I can enhance LC4J so that it can make use of these new methods for enhancing the per request calls but merging this PR change should not break the existing contract. Once this is merged and a new version created, I can work on the PR on |
| Is there a way to make this change non-breaking? |
I don't think there's a good way to do that without having to change the Quarkus extension. But even if the extension was to be upgraded, the change would simply be as simple as this if there is no need for per-request calls. Also, it appears that the repo is in maintenance mode already since there is a message on the repo that says @langchain4j do you think we could proceed to have this merged first and I could raise a separate PR for Quarkus Extension later |
bc207e7 to ce7b977 Compare | @langchain4j It appears that the It also looks like the OPENAI key is not set up for the repo so tests are failing to run |
When you add new abstract methods to the class/interface, you can always add a default implementation (e.g. throwing a "not implemented" exception) to not break things for everyone who extends this interface. They can always provide their implementation when needed, but they won't be forced to do so if they are not interested in this particular feature.
Please add new models and mark
I've updated the key, could you please check? |
Ok, I got the intention now - I've made those methods throw
That is done - also I have marked some test cases to exclude
It looks like the tests are still failing because it can't find |
16a2f47 to f256821 Compare f256821 to ea94b90 Compare
langchain4j left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@singularity-sg thanks a lot!
Yes, it is in secrets. I've run all the tests locally and they are green |
The tests are all passing locally for me when I set the |
| @singularity-sg oh sorry, I forgot to merge it. I guess tests fail because you did not set |
Thank you for your help once again! much appreciated 🙏🏼 |



Description
In order to better facilitate integration with OpenAI proxies, we want to be able to inject headers per request so that these headers could be used for auxiliary handling of actual OpenAI calls e.g use case being usage tracking and rate limits.
Approach
The approach is to retain much of the OpenAiClient interface and calls but extending the capabilities to send extra headers per request. This requires us to open up the
abstractmethods to take in a new inner class inOpenAiClient.OpenAiClientContextas a method argument. We can extend this context so that other implementations ofOpenAiClientabstract class could use the same context object to add in other metadata if needed for executing OpenAi API methods.For now, I've only added
headersin theOpenAiClientContextbut I could imagine this being used for other cases as well. The default signature is retained for theOpenAiClientso we can still callchatCompletion(ChatCompletionRequest)as it is and it will simply pass along a defaultOpenAiClientContextcc: @langchain4j