Call queueing does not work

[spearmootz]

Describe the bug
Api is not called, or at least fm doesnt seem to respond like it

Expected behavior
api is supposed to be called.

Code Examples

this never finished

const marpat = require("marpat");
const fmsApiClient = require("fms-api-client");


(async () => {

    await marpat.connect('nedb://memory');
    const client = fmsApiClient.Filemaker.create({
        //Credentials
        concurrency: 10
    });
    await client.save();

    const promises = [];
    let x = 0;
    while (x < 10) {
       
        try {
          promises.push ( 
            client.create('Accounts Data API Test | Data API', {account_number: x++ })
            )
        } catch (error) {
            console.error(error);
        }
    }
    console.log('called all');
    await Promise.all(promises);
    console.log('done');
})()

but if we change

promises.push ( 
            client.create('Accounts Data API Test | Data API', {account_number: x++ })
            )

to

            await client.create('Accounts Data API Test | Data API', {account_number: x++ })

it creates all but slow

Tests
i will attempt to do so

Additional context

[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