file_ids incorrectly deprecated, causing runtime errors

[ffxsam]

Confirm this is a Node library issue and not an underlying OpenAI API issue

• This is an issue with the Node library

Describe the bug

I just updated openai from 4.28.0 to 4.48.2. I'm now seeing this error in my Lambda function:

400 Unknown parameter: threads.messages[0].file_ids

If I open my code, I see that file_ids is no longer a valid property in the code snippet cited below.

No overload matches this call.
  Overload 1 of 3, '(body: ThreadCreateAndRunParamsNonStreaming, options?: RequestOptions<unknown> | undefined): APIPromise<Run>', gave the following error.
    Object literal may only specify known properties, and 'file_ids' does not exist in type 'Message'.
  Overload 2 of 3, '(body: ThreadCreateAndRunParamsStreaming, options?: RequestOptions<unknown> | undefined): APIPromise<Stream<AssistantStreamEvent>>', gave the following error.
    Object literal may only specify known properties, and 'file_ids' does not exist in type 'Message'.
  Overload 3 of 3, '(body: ThreadCreateAndRunParamsBase, options?: RequestOptions<unknown> | undefined): APIPromise<Run | Stream<AssistantStreamEvent>>', gave the following error.
    Object literal may only specify known properties, and 'file_ids' does not exist in type 'Message'.

I'm curious why a breaking change was introduced, and openai's major version was not bumped to 5.x.x as is standard practice with semver. Looking through the changelog, I also see no mention of breaking changes.

To Reproduce

See code snippet.

Code snippets

let run = await openai.beta.threads.createAndRun({
    assistant_id: OPENAI_ASSISTANT_ID,
    thread: {
      messages: [
        {
          role: 'user',
          content:
            'Analyze the attached files.\n\n' +
            customInstructions
              .map(
                (instruction) =>
                  `If you think the vendor is ${instruction.vendorName}: ` +
                  instruction.instructions
              )
              .join('\n\n'),
          file_ids: savedFiles.map((file) => file.id),
        },
      ],
    },
  });

OS

macOS

Node version

Node v20.14.0

Library version

openai 4.48.2

[meorphis]

Hey @ffxsam sorry for the trouble here. I agree that the changelog could have been clearer. The convention that we are using is that breaking changes in the beta namespace (e.g. openai/resources/beta/threads/threads) will not result in a major version bump, since we are still actively iterating on these APIs.

The equivalent in the latest version would be:

let run = await openai.beta.threads.createAndRun({
    assistant_id: OPENAI_ASSISTANT_ID,
    thread: {
      messages: [
        {
          role: 'user',
          content:
            'Analyze the attached files.\n\n' +
            customInstructions
              .map(
                (instruction) =>
                  `If you think the vendor is ${instruction.vendorName}: ` +
                  instruction.instructions
              )
              .join('\n\n'),
          attachments: savedFiles.map((file) => {file_id: file.id}),
        },
      ],
    },
  });

[ffxsam]

@meorphis Thanks for the help! I understand you have a convention, but package managers follow their own convention. Beta packages use 0.x.y for their versioning, which prevents breaking changes during routine package updates. Just something to keep in mind for future breaking changes with the OpenAI SDK. It would be appreciated to at least have notes in the changelog that point out anything that could potentially break production applications.

[meorphis]

Thanks for the feedback. There's unfortunately no perfect option here. Since the openai package itself is not (and cannot be) a beta package, if we wanted the beta functionality to have its own versioning we would have to split it into its own package and users of the openai package wouldn't have access to these features. So that's why we've landed where we have. But we do understand that the convention we're using is uncommon so it's helpful to hear from users when it breaks workflows. We really appreciate the feedback and will continue to evaluate the options in future releases.