metarhia / impress

Enterprise application server for Node.js and Metarhia private cloud ⚡
https://metarhia.com
MIT License
966 stars 128 forks source link

Local API endpoint queue settings doesn't work #1945

Closed KLarpen closed 9 months ago

KLarpen commented 9 months ago

Impress and Node.js versions

Impress: 3.0.13 Node: 20.9.0, 18.18.2

Platform

macOS 14.1.2 Darwin Kernel Version 23.1.0: Mon Oct 9 21:27:24 PDT 2023; root:xnu-10002.41.9~6/RELEASE_ARM64_T6000 arm64

Describe the bug

Local settings of the queue, placed directly into API endpoint module, not working at all. Any values there just doesn't applied, so the queue restrictions on the endpoint doesn't applied as well.

To Reproduce

  1. Start with Example project
  2. Check that general queue config at application/config/server.js contains

https://github.com/metarhia/impress/blob/4cabe81e1cef6870a10d7c7b020f8618db3bdbf3/test/config/server.js#L15-L19

  1. Put file application/api/example/testQueue.js
({
  access: 'public',
  queue: {
    concurrency: 1,
    size: 1,
    timeout: 1500,
  },
  async method() {
    await node.timers.promises.setTimeout(2900);
    return { returned: true };
  },
});
  1. Run server
  2. Open browser tab with DevTools (console & network tabs in it)
  3. Check that WS request api is active and there is messages
  4. Type in console await api.example.testQueue(); and call it 3 times quickly (without awaiting for results)
  5. All of request will return successfully after obvious concurrent execution despite our local queue setup.
    {"type":"call","id":4,"method":"example/testQueue","args":{}} 
    {"type":"call","id":5,"method":"example/testQueue","args":{}}
    {"type":"call","id":6,"method":"example/testQueue","args":{}}
    {"type":"callback","id":4,"result":{"returned":true}}
    {"type":"callback","id":5,"result":{"returned":true}}
    {"type":"callback","id":6,"result":{"returned":true}}

Expected behavior

Local queue settings of the API endpoint must be applied to control behaviour. Reproducing example above we expect :

Screenshots

No response

Additional context

I'm already investigating possible fix to make pull request.