sequelize-pool icon indicating copy to clipboard operation
sequelize-pool copied to clipboard

Destroying inactive resources can cause unhandled promise rejection

Open sfc-gh-ljagielski opened this issue 11 months ago • 1 comments

Hi, I wanted to share a possible bug. If destroy method passed to Pool constructor is async, then its rejection might cause an unhandled promise rejection, for example in idle timer (it doesn't seem to await resource destruction). Here's a test that demonstrates the behavior (it fails with an unhandled rejection)

import * as tap from 'tap';
import { Pool } from '../../src';

tap.test('should finish the test without unhandled rejection', async (t) => {
  const pool = new Pool<{ foo: number }>({
    create: () => Promise.resolve({ foo: 1 }),
    // Pool doesn't await destroy when closing idle connections
    destroy: () => Promise.reject('Ohnoo'),
    validate: () => true,
    max: 5,
    min: 0,
    idleTimeoutMillis: 500,
    reapIntervalMillis: 1000,
  });

  const res = await pool.acquire(); // create first resource, it will be kept
  t.equal(res, { foo: 1 });
  pool.release(res);
  // wait 3 seconds for idle timer to cause unhandled rejection
  await new Promise((resolve) => {
    setTimeout(resolve, 3000);
  });
  await pool.destroyAllNow().then(
    () => console.log('Destroyed'),
    (err) => console.log('Error, whatever' + err),
  );
});

Thanks for looking at this,

sfc-gh-ljagielski avatar Mar 06 '24 10:03 sfc-gh-ljagielski

Thanks for reporting this, I have taken a look at this.

When the pool.release is called for a given resource, that method does not wait for the pool.destroy method, as pool.release itself is sync method. This can cause un-handled rejection if factory.destroy is rejected.

The simplest way to solve this would be to convert the pool.release method to async. This would be a breaking change.

sushantdhiman avatar Mar 14 '24 11:03 sushantdhiman