Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feat/messages api #546

Merged
merged 17 commits into from
Nov 13, 2023
Merged

Conversation

urjitbhatia
Copy link
Contributor

@urjitbhatia urjitbhatia commented Nov 7, 2023

This branch implements thread messages API

Sibling to the threads api implementation #536

Copy link

codecov bot commented Nov 8, 2023

Codecov Report

Merging #546 (e152f43) into master (d6f3bdc) will increase coverage by 0.09%.
Report is 2 commits behind head on master.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #546      +/-   ##
==========================================
+ Coverage   98.22%   98.31%   +0.09%     
==========================================
  Files          22       23       +1     
  Lines        1181     1247      +66     
==========================================
+ Hits         1160     1226      +66     
  Misses         15       15              
  Partials        6        6              
Files Coverage Δ
messages.go 100.00% <100.00%> (ø)

- go map access is not deterministic
- this can lead to a route: /foo/bar/1 matching /foo/bar before matching /foo/bar/1 if the map iteration go through /foo/bar first since the regex match wasn't bound to start and end anchors
- registering handlers now converts * in routes to .* for proper regex matching
- test server route handling now tries to fully match the handler route
@henomis
Copy link
Contributor

henomis commented Nov 9, 2023

Hi, to cover your tests you need to add entries in TestCases in client_test.go

messages.go Outdated Show resolved Hide resolved
messages.go Outdated Show resolved Hide resolved
messages.go Outdated

type MessageContent struct {
Type string `json:"type"`
Text MessageText `json:"text"`
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
Text MessageText `json:"text"`
Text *MessageText `json:"text,omitempty"`
ImageFile *ImageFile `json:"image_file,omitempty"` // <- define this one

@wti806
Copy link

wti806 commented Nov 10, 2023

May I ask when the message API would be ready?

@urjitbhatia
Copy link
Contributor Author

urjitbhatia commented Nov 10, 2023 via email

@urjitbhatia
Copy link
Contributor Author

TestCases

Adding the test cases...

However, when looking at these tests - It makes sense to push for a high coverage but some of the work done to keep it high seems forced. For example, covering the branch when the API returns an error.

I'd suggest rethinking the requirement a little bit - it makes sense to cover the main logic but this test seem to add very little or no value - https://github.com/sashabaranov/go-openai/blob/master/client_test.go#L184 - am I missing something in the value of this test? It doesn't actually test that the request building failed due to bad/missing params, only that an if err was added to the calls - lmk if that's the intended use anyways.

@henomis @sashabaranov

messages.go Outdated
}
type MessageText struct {
Value string `json:"value"`
Annotations []interface{} `json:"annotations"`
Copy link
Owner

Choose a reason for hiding this comment

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

let's use any instead of interface{}

messages.go Outdated
encodedValues = "?" + urlValues.Encode()
}

urlSuffix := fmt.Sprintf("/threads/%s%s%s", threadID, messagesSuffix, encodedValues)
Copy link
Owner

Choose a reason for hiding this comment

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

Just a suggestion: changing messagesSuffix from /messages to messages would make formatting more consistent without %s%s mixed with %s/%s

@sashabaranov
Copy link
Owner

sashabaranov commented Nov 12, 2023

@urjitbhatia thank you so much for the PR! A couple of minor additions and let's merge it 🙌🏻

However, when looking at these tests - It makes sense to push for a high coverage but some of the work done to keep it high seems forced. For example, covering the branch when the API returns an error.
I'd suggest rethinking the requirement a little bit - it makes sense to cover the main logic but this test seem to add very little or no value - https://github.com/sashabaranov/go-openai/blob/master/client_test.go#L184 - am I missing something in the value of this test?

You know, when I started working on this library a couple of years earlier, I would agree with you. I didn't see any point in extensive testing except for integration tests with the actual API to check that the client actually works.

Now, I have come to realise a couple of things about testing:

  • It's easy to test the "happy path", but to test error cases, you need to design the code with clear interfaces and separation of concerns (RequestBuilder and ErrorAccumulator are good examples of that)
  • You are either forcing code coverage or dealing with the code base with a constant decline of code coverage sometime in the future. I would prefer the former, especially for such a widely-used library
  • ~100% code coverage makes it simpler to accept changes into the codebase — it's just easier to trust the code that way

I think the requirement of copy-pasting 3 lines of tests per client method is a reasonable requirement for all these benefits.

So the way forward is to actually reach 100% coverage, add more randomisation(see #491), fuzzing, and integration tests in CI.

It doesn't actually test that the request building failed due to bad/missing params

Currently, the validation happens on the OpenAI backend side. I'll be happy to accept any client validation, though 👍🏻

@urjitbhatia
Copy link
Contributor Author

@sashabaranov added the style fixes from the last review :)

@496672097
Copy link

"I need help. How can I obtain the result of a run after executing the CreateRun() method?"
image

@vsumit89
Copy link

HI @sashabaranov @urjitbhatia any updates by when this PR will be merged.
Thanks for all the work you guys have been putting in!

@sashabaranov sashabaranov merged commit b7cac70 into sashabaranov:master Nov 13, 2023
3 checks passed
// CreateMessage creates a new message.
func (c *Client) CreateMessage(ctx context.Context, threadID string, request MessageRequest) (msg Message, err error) {
urlSuffix := fmt.Sprintf("/threads/%s/%s", threadID, messagesSuffix)
req, err := c.newRequest(ctx, http.MethodPost, c.fullURL(urlSuffix), withBody(request))

Choose a reason for hiding this comment

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

Any reason for not adding withBetaAssistantV1() here ? When using CreateMessage I still get the error You must provide the 'OpenAI-Beta' header to access the Assistants API. Please try again by setting the header 'OpenAI-Beta: assistants=v1'.

Copy link
Contributor

Choose a reason for hiding this comment

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

@lowczarc I ran into this and submitted: #566

maerlyn5 pushed a commit to prassoai/go-openai that referenced this pull request Nov 22, 2023
* fix test server setup:
- go map access is not deterministic
- this can lead to a route: /foo/bar/1 matching /foo/bar before matching /foo/bar/1 if the map iteration go through /foo/bar first since the regex match wasn't bound to start and end anchors
- registering handlers now converts * in routes to .* for proper regex matching
- test server route handling now tries to fully match the handler route

* add missing /v1 prefix to fine-tuning job cancel test server handler

* add create message call

* add messages list call

* add get message call

* add modify message call, fix return types for other message calls

* add message file retrieve call

* add list message files call

* code style fixes

* add test for list messages with pagination options

* add beta header to msg calls now that sashabaranov#545 is merged

* Update messages.go

Co-authored-by: Simone Vellei <[email protected]>

* Update messages.go

Co-authored-by: Simone Vellei <[email protected]>

* add missing object details for message, fix tests

* fix merge formatting

* minor style fixes

---------

Co-authored-by: Simone Vellei <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants