Looking over some edge cases in the event loop code made me wonder how tolerant it is to multiple requests coming in for the same remote (and therefore session) before an existing request is completed. Review the event loop with this in mind. At the very least start adding tests with concurrent in flight requests to attempt to discover issues.
This also brings up questions session cache, being clear about how cache is retained on both the requester and provider. The spec currently focuses on provider cache, but it feels like this may need clarification. Placeholder for me to refine my thinking...
The spec says
The Requestor MAY garbage collect its session state as soon as it has all of the blocks for the structure, minus the subgraphs marked as unavailable
This is the cache currently on the http client. Think about this as it relates to concurrent sessions though.
This will likely be split into 1) documenting current limitations around concurrent requests for the same session, and 2) tracking longer term work to allow for parallel requests if deemed necessary.
Looking over some edge cases in the event loop code made me wonder how tolerant it is to multiple requests coming in for the same remote (and therefore session) before an existing request is completed. Review the event loop with this in mind. At the very least start adding tests with concurrent in flight requests to attempt to discover issues.
This also brings up questions session cache, being clear about how cache is retained on both the requester and provider. The spec currently focuses on provider cache, but it feels like this may need clarification. Placeholder for me to refine my thinking...
The spec says
This is the cache currently on the http client. Think about this as it relates to concurrent sessions though.
ETA: 2023-10-31