-
Notifications
You must be signed in to change notification settings - Fork 908
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
Switch from node-fetch
to undici
#402
Conversation
const defaultHttpAgent: Agent = new KeepAliveAgent({ keepAlive: true, timeout: 5 * 60 * 1000 }); | ||
const defaultHttpsAgent: Agent = new KeepAliveAgent.HttpsAgent({ keepAlive: true, timeout: 5 * 60 * 1000 }); | ||
const defaultHttpAgent = new uf.Agent({ keepAliveTimeout: 5 * 60 * 1000 }); | ||
const defaultHttpsAgent = new uf.Agent({ keepAliveTimeout: 5 * 60 * 1000 }); |
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.
Is this necessary to get reasonable keepAlive
behavior? IIRC, node-fetch
didn't do keepAlive by default but if undici does, maybe we don't need to construct a default agent after all?
(note we also have weird timeout shenanigans elsewhere to bump the agent's timeout so that a long timeout for a given request isn't cut short by the agent's timeout; not sure whether that'd still be necessary or would need adjustment.)
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.
I'd have to go look at the default agent timeout to be sure
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.
FYI: undici will honor the keep-alive hint from the server.
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.
This is looking clean & great so far! Thank you @Ethan-Arrowood !
One thing to note is that with undici, it looks like |
@@ -125,7 +125,7 @@ export async function toFile( | |||
} | |||
} | |||
|
|||
return new File(bits, name, options); | |||
return new File(bits as (string | Blob | NodeJS.ArrayBufferView)[], name, options); |
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.
I couldn't for the life of me figure out how to get this type to work. Help appreciated!
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.
heh, I believe it, can try to take a look soon… likely thursday…
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.
@Ethan-Arrowood I think undici
's type for the fileBits
parameter is wrong, their own JSDoc says it accepts ArrayBuffer
s, but the type annotation only accepts ArrayBufferView
s, which ArrayBuffer
s aren't assignable to.
Yes this an important distinction. It will be a Node.js Web Stream instead. This is to spec so that code is actually interoperable. |
You mean, interoperable with web streams, not Node ones, right? So it will be breaking? Is there any way we can ease that migration for developers? |
Current, interoperable with web streams. Also meaning that when you use it in code that runs in both browser and on the server it behaves the same. There does exist some utilities for users to transform one to the other. And they are fairly close in implementation so some users won't even notice a difference. The key here is that this breaking change is intentional. Understand if you want that to happen in a major version of this library. Otherwise, if this library tried to do something else you'd just be kicking the can down the road. True interoperability should not have anything other than Web Streams. If true interoperability isn't the absolute goal, we could add a transform to this library and keep Node users on Node streams. |
I'm probably leaning towards a major version bump in that case. I imagine
shimming a web ReadableStream to also be compatible with a node Readable
stream would be pretty gross. But if there is a library that does that
sanely, it'd make the rollout much easier.
For what it's worth I doubt a huge number of people are likely to be
relying on the raw response so far, so I doubt it'll be a very painful
major version.
…On Wed, Nov 8 2023 at 8:39 AM, Ethan Arrowood ***@***.***> wrote:
Current, interoperable with web streams. Also meaning that when you use it
in code that runs in both browser and on the server it behaves the same.
There does exist some utilities for users to transform one to the other.
And they are fairly close in implementation so some users won't even notice
a difference. The key here is that this breaking change is intentional.
Understand if you want that to happen in a major version of this library.
Otherwise, if this library tried to do something else you'd just be kicking
the can down the road. True interoperability should not have anything other
than Web Streams. If true interoperability isn't the absolute goal, we
could add a transform to this library and keep Node users on Node streams.
—
Reply to this email directly, view it on GitHub
<#402 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAFL6LT2IDSS6VVMHH5UCI3YDOYVBAVCNFSM6AAAAAA6OBVVX6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMBSGI3DCOJWGU>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Hey, sorry, just checking in – are you blocked on me here? |
No - haven't gotten back around to this. Need to still figure out how to run tests (still haven't created an OpenAI key). Do you have CI you could enable for this PR? I'll update and mark it "ready for review" so GitHub prompts it too. |
Sadly we don't run CI in public for this repo yet, just internally. The steps to test it locally are: yarn
OPENAI_API_KEY=… yarn ts-node ecosystem-tests/cli.ts
npx prism mock https://github.com/openai/openai-openapi/raw/master/openapi.yaml & # or in a separate tab.
yarn test |
Updated failing types I believe. Still cannot run tests. Not sure what's going wrong. Maybe my local env is in a bad state. I think this is very close, maybe a maintainer more familiar with the shim and test matrix can take it over the finish line. The most important detail here is that Node.js now has an actual spec compliant Fetch implementation. Its types are different and most importantly it now returns Web Streams instead of Node.js Streams (spec compliant). This is more expected IMO as fetch should do as fetch is documented to do. Node.js makes available a |
Amazing, thank you so much @Ethan-Arrowood ! Finishing off those tests ourselves sounds totally fair; we have a lot on our plate right not but will try to take a look at getting this over the line soon. |
I've approved running the CI workflow. Looks like it is failing with a module error:
https://github.com/openai/openai-node/actions/runs/6908472736/job/18819218282?pr=402 Perhaps we need to update the workflow to use Node 18 rather than 16? https://github.com/openai/openai-node/blob/master/.github/workflows/ci.yml |
@Ethan-Arrowood can you rebase on master so that the latest CI workflow can be run with Node 18? |
ff0be7c
to
1a1de82
Compare
Looks like CI now runs correctly! Some type errors to fix next it looks like. |
Why are they all coming from the |
1a1de82
to
c2e41fa
Compare
Thanks Atty! I think @jedwards1211 is working on these type errors etc – Ethan, you shouldn't need to take a look. |
When will this be merged into |
Sorry for the annoyance. We're hoping to merge this within the next 6-8 weeks. It will be a breaking change and there are some deep complexities, which is why it'll take longer than one might hope, but we are actively working on it behind the scenes. |
@@ -67,10 +68,11 @@ it(`raw response`, async function () { | |||
|
|||
// test that we can use node-fetch Response API |
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.
This comment probably needs updating
(We are still working on this! Sorry for the delays, everybody) |
Update here is that we're planning on moving entirely to builtin APIs so we won't even need to depend on |
Hey team - I am going to close this PR for now, given our imminent plans to migrate to built-in |
@kwhinnery-openai is there a tracking issue for this fix? Thanks! |
For folks following along, it looks like #1237 replaced |
Closes #392