Client lifecycle diagram

[Ethan-Arrowood]

Closes #532

Opening as a draft to start getting some feedback. I've read through the source code, tests, and existing documentation to come up with this. It may not be correct + I feel like I want to expand the "processing" state since there is a lot that happens inside of that.

I'd love to integrate parts of the API here too like specific methods calls, emitted events, and property values

[ronag]

It won’t disconnect until keep alive timeout.

[Ethan-Arrowood]

It won’t disconnect until keep alive timeout.

Yes good point. I'll include some more details one that

[ronag]

I thinking you should have another state which is just connected.

Idle - pending - running - keep alive - closing - destroyed

[Ethan-Arrowood]

I thinking you should have another state which is just connected.
Idle - pending - running - keep alive - closing - destroyed

From what I can tell the Client never actually sits in a "connected" state. Once dispatch is called the Client immediately creates that socket connection and begins processing the request; even if it does not resolve the response back to the user immediately (as in the case of the async functions)

[codecov-io]

Codecov Report

Merging #567 (372153d) into master (e35706c) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #567   +/-   ##
=======================================
  Coverage   99.16%   99.16%           
=======================================
  Files          16       16           
  Lines        1444     1444           
=======================================
  Hits         1432     1432           
  Misses         12       12           

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e35706c...372153d. Read the comment docs.

[Ethan-Arrowood]

Edit: This is an old diagram - up to date image is in the commit

@ronag what do you think about this breakdown of the processing state?

[ronag]

@Ethan-Arrowood maybe we could have a voice call? How does your day look today?

[Ethan-Arrowood]

Im free for the next couple hours! Send me an invite for whenever [edit: removed email]

[ronag]

We had a call and discussed the life cycle and also other ways to make the code easier to understand.

[Ethan-Arrowood]

Updated the diagram based on our conversation @ronag - I'm working on the detailed state descriptions now so its better understood as well

[mcollina]

In the processing sub-diagram, you need a keep-alive state that goes back to the beginning or times out.

[Ethan-Arrowood]

In the processing sub-diagram, you need a keep-alive state that goes back to the beginning or times out.

IMO this is what the pending state represents, connected but not processing requests. The keepAlive event is what transitions the Client from processing back to pending. And when that socket connection timesout, the timeOut event transitions from pending to init.

[mcollina]

I got confused by having both done and keep alive ending in the same dot.

[mcollina]

lgtm

[Ethan-Arrowood]

@nodejs/undici please review and merge at your earliest convenience

[Ethan-Arrowood]

Just rebased and moved the file to the docsify site 😄

[mcollina]

still lgtm

[Ethan-Arrowood]

Okay now i think this is good to go. I messed things up with docsify links in the initial site build. But this should clean up everything

[mcollina]

lgtm