Call queueing does not work

[spearmootz]

Call queueing does not work

[Luidog]

Thank you for raising this issue and contributing a test @spearmootz. I added the test you created to the sessions file on my current working branch.

Once you configure a .env file in the tests directory you can call npm run test-session to call the test you contributed as part of the session test suite.

The test confirms the client will become unresponsive when a large number of requests are made before a session is available. This behavior is only exhibited when there are no sessions available before request processing.

I found that more than 9 requests for a client with concurrency set to 25, and more than 18 requests for a client with concurrency set to 35 caused the behavior.

I am inclined to add an iterator to the agent watcher process to monitor for this behavior and force the agent to resolve a session to prevent the request queue from stopping.

A PR to fix this behavior would be welcome.

[spearmootz]

I am in the process of examining the code today and pinpoint the issue. Problem is that the solution you have is very clever and that means that I have to figure out the cleverness. Im making good progress so I should potentially have something today.

…

On Mon, Jun 8, 2020, 10:22 AM Lui de la Parra ***@***.***> wrote: Thank you for raising this issue and contributing a test @spearmootz <https://github.com/spearmootz>. I added the test you created to the sessions file on my current working branch <https://github.com/Luidog/fms-api-client/tree/security-fix>. Once you configure a .env file <https://github.com/Luidog/fms-api-client/blob/security-fix/test/env.manifest> in the tests directory you can call npm run test-session to call the test you contributed as part of the session test suite. The test confirms the client will become unresponsive when a large number of requests are made before a session is available. This behavior is only exhibited when there are no sessions available before request processing. I found that more than 9 requests for a client with concurrency set to 25, and more than 18 requests for a client with concurrency set to 35 caused the behavior. I am inclined to add an iterator to the agent watcher process to monitor for this behavior and force the agent to resolve a session to prevent the request queue from stopping. A PR to fix this behavior would be welcome. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#81 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEWSVSQEOP2XNHTCAINVMODRVTX2PANCNFSM4NVCBTHQ> .

[spearmootz]

here is what i have gathered so far. I am seeing a request successfully go through all the paces.

then i see a second request go through, make the call to fm successfully. but then it gets here

return typeof pending.resolve === 'function'
          ? pending.resolve(request)
          : request

pending.resolve is a function as expected but then i dont see it being handled in the interceptor like the other one is.

i think it has to do with the interceptor logic. still working on it