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

OpenAI integration: strconv.ParseFloat: parsing "undefined" #4697

Open
mufeez-amjad opened this issue Sep 17, 2024 · 1 comment · May be fixed by #4706
Open

OpenAI integration: strconv.ParseFloat: parsing "undefined" #4697

mufeez-amjad opened this issue Sep 17, 2024 · 1 comment · May be fixed by #4706
Assignees

Comments

@mufeez-amjad
Copy link

We're seeing a large number of the following error on Datadog:

2024-09-17 21:39:35 UTC | CORE | ERROR | (comp/dogstatsd/server/server.go:634 in errLog) | Dogstatsd: error parsing metric message '"openai.tokens.completion:undefined|d|#service:<service>,env:prod,version:1.29399.0,error:0,org:<org>,endpoint:/v1/embeddings,model:text-embedding-ada-002"': could not parse dogstatsd metric values: strconv.ParseFloat: parsing "undefined": invalid syntax

(the error is specifically the float conversion of undefined and we're only seeing it for embeddings). We have the OpenAI integration enabled which appears to be working for chat completion requests.

I briefly looked through the corresponding code in the tracer:

const completionTokens = spanTags['openai.response.usage.completion_tokens']

is the value that is parsed, and is set here:

completionTokens = body.usage.completion_tokens

This appears to be the right part of the code given that the openai response is for an embeddings.create request:

I checked with version 4.62.0 of the openai npm SDK and observed that both the return type and the actual response don't have body.usage.completion_tokens as a valid field of the response:

image

https://github.com/openai/openai-node/blob/7110f07cb79f27f69341b01b75f8a1f102ceab21/src/resources/embeddings.ts#L41-L56

Is there something I'm missing or does the tracing code need to account for this field not being present?

@sabrenner
Copy link
Collaborator

Hi @mufeez-amjad, thanks for raising this issue! Yeah, it does look like we should just not include these usage counts if not present. I'll put up a fix for this and link it to this issue 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants