Error: invalid bucket size spec: undefined

[efams]

Hi,
after last git pull i get this error when i try to start a simulation.
Lubuntu: 17.10

Error: invalid bucket size spec: undefined
at BucketSize.parse (/home/enri/gdax/zenbot/node_modules/timebucket/lib/bucket-size.js:15:21)
at new BucketSize (/home/enri/gdax/zenbot/node_modules/timebucket/lib/bucket-size.js:5:21)
at Bucket.resize (/home/enri/gdax/zenbot/node_modules/timebucket/lib/bucket.js:30:14)
at Command. (/home/enri/gdax/zenbot/commands/sim.js:84:51)
at Command.listener (/home/enri/gdax/zenbot/node_modules/commander/index.js:315:8)
at emitTwo (events.js:126:13)
at Command.emit (events.js:214:7)
at Command.parseArgs (/home/enri/gdax/zenbot/node_modules/commander/index.js:653:12)
at Command.parse (/home/enri/gdax/zenbot/node_modules/commander/index.js:475:21)
at /home/enri/gdax/zenbot/zenbot.js:39:11
at /home/enri/gdax/zenbot/boot.js:24:7
at f (/home/enri/gdax/zenbot/node_modules/once/once.js:25:25)
at Glob. (/home/enri/gdax/zenbot/node_modules/glob/glob.js:151:7)
at emitOne (events.js:116:13)
at Glob.emit (events.js:211:7)
at Glob._finish (/home/enri/gdax/zenbot/node_modules/glob/glob.js:197:8)
at done (/home/enri/gdax/zenbot/node_modules/glob/glob.js:182:14)
at Glob.processGlobStar2 (/home/enri/gdax/zenbot/node_modules/glob/glob.js:637:12)
at /home/enri/gdax/zenbot/node_modules/glob/glob.js:626:10
at RES (/home/enri/gdax/zenbot/node_modules/inflight/inflight.js:31:16)
at f (/home/enri/gdax/zenbot/node_modules/once/once.js:25:25)
at lstatcb (/home/enri/gdax/zenbot/node_modules/glob/glob.js:519:7)

Thx
Enri

[haxwell]

I'll take this.. I think it is somehow related to my PR #926.

[haxwell]

See PR #940 .

[canselcik]

I'm having the exact same problem. I tried to see if I could cherry-pick some of your changes but it isn't clear which ones are bundled together. Are older releases not having this issue?

[haxwell]

@canselcik all my recent changes are in.. you should be able to pull the master branch, and not run into this problem. And no, older releases would not have this specific problem.

[canselcik]

Sounds good, thanks @haxwell. I'll give it a try right now.

[canselcik]

@haxwell Pulling master and rebuilding didn't work. Or perhaps it did but it brought up another issue. And I do have a local fix for it.

After the changes, sure, the trade subcommand works now, however now balance is broken with:

➜  zenbot git:(master) ✗ zenbot balance gdax.BTC-USD
/mnt/tempos/zenbot/lib/engine.js:17
    s.exchange = get('exchanges.' + so.selector.exchange_id)
                                                ^
TypeError: Cannot read property 'exchange_id' of undefined
    at /mnt/tempos/zenbot/lib/engine.js:18:49
    <rest of backtrace>

Looks like so is simply s.options. Looking at s:

{ options: { debug: undefined },
  selector:
   { exchange_id: 'gdax',
     product_id: 'BTC-USD',
     asset: 'BTC',
     currency: 'USD',
     normalized: 'gdax.BTC-USD' },
  exchange:
   { name: 'gdax',
     historyScan: 'backward',
     makerFee: 0,
     takerFee: 0.3,
     getProducts: [Function: getProducts],
     getTrades: [Function: getTrades],
     getBalance: [Function: getBalance],
     getQuote: [Function: getQuote],
     cancelOrder: [Function: cancelOrder],
     buy: [Function: buy],
     sell: [Function: sell],
     getOrder: [Function: getOrder],
     getCursor: [Function: getCursor] },
  product_id: 'BTC-USD',
  asset: 'BTC',
  currency: 'USD' }

Looks like the following patch takes care of it:

diff --git a/lib/engine.js b/lib/engine.js
index 9b6bf25..bb5690b 100644
--- a/lib/engine.js
+++ b/lib/engine.js
@@ -13,7 +13,9 @@ module.exports = function container (get, set, clear) {
   var c = get('conf')
   var notify = get('lib.notify')
   return function (s) {
-   var so = s.options
+   var so = s

and everything suddenly works. However this is clearly not the right patch, refactoring so for s and getting rid of so would make more sense. Although even when that's done, that breaks the trade subcommand with the same error. It seems like trade and balance subcommands expect different s objects.

[haxwell]

Yes, the present design shares state between the engine and certain commands. The problem you just found was that balance.js was not putting that state in the same place the engine expected to find it. I have submitted PR #978 to correct this.

Good write-up! The ultimate solution I think will come in refactoring that state to be accessible via one object, rather than two or more as it currently is. This will be part of a unit-testing effort, issue #403.

[LoneWolf345]

Are you still experiencing this problem? If not, consider closing this.