getEntryCreditBlock returns TypeError when calling lower block heights [factomjs 0.2.x]

[OrmEmbaar]

The following code:

const { FactomCli } = require('factom')

const cli = new FactomCli()

cli.getEntryCreditBlock('29c26f3bfdd61f015bc1ad72fddbf643772c408333fbc8603f4bd8f091760fa2')
    .then(block => console.log(block))
    .catch(err => console.log(err))

returns the following TypeError:

TypeError: First argument must be a string, Buffer, ArrayBuffer, Array, or array-like object.
    at Function.Buffer.from (buffer.js:183:11)
    at new EntryCreditBlock (/Users/alex/dev/factom/metrics/node_modules/factom/src/blocks.js:131:39)
    at ecbPromise.then.r (/Users/alex/dev/factom/metrics/node_modules/factom/src/get.js:236:33)
    at tryCatcher (/Users/alex/dev/factom/metrics/node_modules/bluebird/js/release/util.js:16:23)
    at Promise._settlePromiseFromHandler (/Users/alex/dev/factom/metrics/node_modules/bluebird/js/release/promise.js:512:31)
    at Promise._settlePromise (/Users/alex/dev/factom/metrics/node_modules/bluebird/js/release/promise.js:569:18)
    at Promise._settlePromise0 (/Users/alex/dev/factom/metrics/node_modules/bluebird/js/release/promise.js:614:10)
    at Promise._settlePromises (/Users/alex/dev/factom/metrics/node_modules/bluebird/js/release/promise.js:693:18)
    at Async._drainQueue (/Users/alex/dev/factom/metrics/node_modules/bluebird/js/release/async.js:133:16)
    at Async._drainQueues (/Users/alex/dev/factom/metrics/node_modules/bluebird/js/release/async.js:143:10)
    at Immediate.Async.drainQueues (/Users/alex/dev/factom/metrics/node_modules/bluebird/js/release/async.js:17:14)
    at runCallback (timers.js:794:20)
    at tryOnImmediate (timers.js:752:5)
    at processImmediate [as _immediateCallback] (timers.js:729:5)

This appears to happen at lower block heights. For example, the keymr used in the above code snippet is for block height 53135. Conversely, in recent blocks, the above code will return true.

It appears that raw API calls to lower block heights return subtly different formats, which may or may not be the cause of the issue. These are:

1. In recent blocks, the entrycredit-block api call returns either a transaction or minute number at ecblock.body.entries[0]. In early blocks, ecblock.body.entries[0] is occupied by an object with a key serverindexnumber.

2. Recent entry credit blocks do not record the creation of entry credits. In early entry credit blocks, the creation of new entry credits is documented thus:

   {
            "ecpubkey": "17ef7a21d1a616d65e6b73f3c6a7ad5c49340a6c2592872020ec60767ff00d7d",
            "txid": "32006bb2c556923f490a4af3dc7f20ad6a692ca6e3cf4673c7eba41a38e86439",
            "index": 0,
            "numec": 52631
          },

Of these two differences, only difference 1 is consistent in every block. Blocks that do not create entry credits do not have an object as described in 2. The above error will also throw in early blocks that do not contain entry credit creation, so difference 2 is less likely to be the cause.

I cannot find any difference in the header.

[PaulBernier]

Thanks for the complete report Alex. This got fixed in version 0.2.4 exact commit is 0369bec

The library was failing to parse the M1 EntryCredit blocks because of the differences you mentioned. For 1. I confirmed that this is an old unrelevant field so I just ignored it. For 2. I talked with Brian, and it seems that those recording of EC purchases are redundant anyway with what you can find in the Factoid blocks, so I chose to also discard this information in M1 EntryCredit blocks. That way we have a unique and consistent structure for all M1, M2 and M3 EntryCredit blocks without missing any information (because the information of EC purchase is in Factoid blocks anyway).