Cannot start and properly seed DB on offline start

[jrdn91]

trafficstars

Actual Behaviour

I am receiving a Resource Not Found Exception when trying to run sls offline start with a further error of Cannot do operations on a non-existent table

Expected Behaviour

I expect the offline server to start with a DB seeded and running so I can make API requests against it without receiving errors that the DB table is not created or cannot be written to

Steps to reproduce it

Just running sls offline start

https://gist.github.com/Jordan4jc/874a9309348a8b0949ead163bcfd7a06

LogCat for the issue

Stack Trace
ResourceNotFoundException: Cannot do operations on a non-existent table
    at Request.extractError (/Users/jordanriser/workspace/nametags/node_modules/aws-sdk/lib/protocol/json.js:48:27)
    at Request.callListeners (/Users/jordanriser/workspace/nametags/node_modules/aws-sdk/lib/sequential_executor.js:105:20)
    at Request.emit (/Users/jordanriser/workspace/nametags/node_modules/aws-sdk/lib/sequential_executor.js:77:10)
    at Request.emit (/Users/jordanriser/workspace/nametags/node_modules/aws-sdk/lib/request.js:683:14)
    at Request.transition (/Users/jordanriser/workspace/nametags/node_modules/aws-sdk/lib/request.js:22:10)
    at AcceptorStateMachine.runTo (/Users/jordanriser/workspace/nametags/node_modules/aws-sdk/lib/state_machine.js:14:12)
    at /Users/jordanriser/workspace/nametags/node_modules/aws-sdk/lib/state_machine.js:26:10
    at Request.<anonymous> (/Users/jordanriser/workspace/nametags/node_modules/aws-sdk/lib/request.js:38:9)
    at Request.<anonymous> (/Users/jordanriser/workspace/nametags/node_modules/aws-sdk/lib/request.js:685:12)
    at Request.callListeners (/Users/jordanriser/workspace/nametags/node_modules/aws-sdk/lib/sequential_executor.js:115:18)
    at Request.emit (/Users/jordanriser/workspace/nametags/node_modules/aws-sdk/lib/sequential_executor.js:77:10)
    at Request.emit (/Users/jordanriser/workspace/nametags/node_modules/aws-sdk/lib/request.js:683:14)
    at Request.transition (/Users/jordanriser/workspace/nametags/node_modules/aws-sdk/lib/request.js:22:10)
    at AcceptorStateMachine.runTo (/Users/jordanriser/workspace/nametags/node_modules/aws-sdk/lib/state_machine.js:14:12)
    at /Users/jordanriser/workspace/nametags/node_modules/aws-sdk/lib/state_machine.js:26:10
    at Request.<anonymous> (/Users/jordanriser/workspace/nametags/node_modules/aws-sdk/lib/request.js:38:9)
    at Request.<anonymous> (/Users/jordanriser/workspace/nametags/node_modules/aws-sdk/lib/request.js:685:12)
    at Request.callListeners (/Users/jordanriser/workspace/nametags/node_modules/aws-sdk/lib/sequential_executor.js:115:18)
    at callNextListener (/Users/jordanriser/workspace/nametags/node_modules/aws-sdk/lib/sequential_executor.js:95:12)
    at IncomingMessage.onEnd (/Users/jordanriser/workspace/nametags/node_modules/aws-sdk/lib/event_listeners.js:269:13)
    at emitNone (events.js:91:20)
    at IncomingMessage.emit (events.js:185:7)
    at endReadableNT (_stream_readable.js:974:12)
    at _combinedTickCallback (internal/process/next_tick.js:80:11)
    at process._tickDomainCallback (internal/process/next_tick.js:128:9)
From previous event:
    at PluginManager.invoke (/Users/jordanriser/.nvm/versions/node/v6.11.2/lib/node_modules/serverless/lib/classes/PluginManager.js:372:22)
    at PluginManager.run (/Users/jordanriser/.nvm/versions/node/v6.11.2/lib/node_modules/serverless/lib/classes/PluginManager.js:403:17)
    at variables.populateService.then (/Users/jordanriser/.nvm/versions/node/v6.11.2/lib/node_modules/serverless/lib/Serverless.js:102:33)
    at runCallback (timers.js:672:20)
    at tryOnImmediate (timers.js:645:5)
    at processImmediate [as _immediateCallback] (timers.js:617:5)
From previous event:
    at Serverless.run (/Users/jordanriser/.nvm/versions/node/v6.11.2/lib/node_modules/serverless/lib/Serverless.js:89:74)
    at serverless.init.then (/Users/jordanriser/.nvm/versions/node/v6.11.2/lib/node_modules/serverless/bin/serverless:42:50)

[cramhead]

Same problem here.

[cramhead]

I found a work around. It's now how you really want to do things long term, but at least you can work.

1. I do a sls dynamodb start --migrate to start. This will throw the error, but the database is running. I can query it via the http://localhost:8000/shell/
2. sls offline. Note, it doesn't include the start parameter. I expect this means that it doesn't raise the start event. Unfortunately, I don't know much of what that entails.

Also, the https://github.com/99xt/serverless-react-boilerplate example works fine.

Would anyone have some insight of further debugging this issue?

[ivanfoong]

@cramhead I faced the same issue. But I fixed it by adding migrate config, like the following configuration sample

custom:
  dynamodb:
    start:
      migrate: true

[pakindessama]

I found a work around. It's now how you really want to do things long term, but at least you can work.

1. I do a `sls dynamodb start --migrate` to start. This will throw the error, but the database is running. I can query it via the http://localhost:8000/shell/

2. `sls offline`. Note, it doesn't include the start parameter. I expect this means that it doesn't raise the start event. Unfortunately, I don't know much of what that entails.

Also, the https://github.com/99xt/serverless-react-boilerplate example works fine.

Would anyone have some insight of further debugging this issue?

Any solution about this issue?? The work around proposed by @cramhead works but, as he mentioned, I don't think that is the best approach, PS: I already added migrate in the config file.