Should `spawn` ensure that DynamoDB local started up completely?

[mxro]

Using dynamo-db-local as part of a test suite, I noticed that simply calling spawn is not sufficient to have the DynamoDB instance ready to be used in test logic.

When using the java command, I needed to add some additional logic to ensure DynamoDB is available on the port:

  const pr = dynamoDBLocal.spawn({
      port: MAPPED_PORT,
      path: null,
      detached: false,
    });
    await waitPort({
      host: 'localhost',
      port: MAPPED_PORT,
    });

When using the docker command, I needed to wait for the port plus add an additional sleep (otherwise would get 'socket errors' from the AWS SDK):

 const pr = dynamoDBLocal.spawn({
      port: MAPPED_PORT,
      command: 'docker',
      name: containerName,
      path: null,
      detached,
    });
    await waitPort({
      host: 'localhost',
      port: MAPPED_PORT,
    });
    // giving DynamoDB some extra time to start up
    await new Promise<void>((resolve) => {
      setTimeout(resolve, 5000);
    });

Should this be something built into the library? Or is it already and I need to set this up in a different way?

For reference, here the AWS SDK error received when not giving DynamoDB the extra time to start up:

    AWS SDK error wrapper for TimeoutError: socket hang up

      at asSdkError (../../../../.yarn/cache/@smithy-middleware-retry-npm-3.0.15-016bf2eb8e-d086642ba6.zip/node_modules/@smithy/middleware-retry/dist-cjs/index.js:103:10)
      at ../../../../.yarn/cache/@smithy-middleware-retry-npm-3.0.15-016bf2eb8e-d086642ba6.zip/node_modules/@smithy/middleware-retry/dist-cjs/index.js:327:21
      at ../../../../.yarn/cache/@aws-sdk-middleware-logger-npm-3.609.0-2e9c05cfa1-c21b6ec3a2.zip/node_modules/@aws-sdk/middleware-logger/dist-cjs/index.js:34:22

[chrisguttandin]

Yes, I think that would be a good addition. I usually do something like this:

const dynamoDbLocalProcess = spawn(/* ... */);

await new Promise((resolve) => {
    dynamoDbLocalProcess.stdout.once('data', () => resolve());
});

When doing it like that instead of waiting for the port we could also parse the logged output to check for errors. Checking for the port may also trigger some false positives when specifying a port that's already in use by another application.

Does the snippet above work for you, too?