iotaledger / iota.js

IOTA JavaScript
966 stars 286 forks source link

Default transfer array for promoteTransaction is not set correctly #305

Closed pph7 closed 5 years ago

pph7 commented 5 years ago

Bug description

When calling promoteTransaction() without specifying a transfer array it throws an error. I am aware that in the documentation, the transfer array is not optional. However, there is one example in the documentation that does not use the transfer array:

https://github.com/iotaledger/iota.js/tree/next/packages/core#module_core.isPromotable

Also, in the source code, a default value is provided:

https://github.com/iotaledger/iota.js/blob/2ad21079c655f7c7527ad392d896b85e257f9f34/packages/core/src/createPromoteTransaction.ts#L21-L28

This is because

Array(n).map(spammer)

does not return an array of spammer objects. Instead it returns an array of uninitialized arrays. This can be easily verified:

new Array(1).map(1)

will produce

[empty]

and not the expected array [1].

Possibile solutions: use

new Array(1).fill().map()

BTW, it seems that generateSpam() is alway only called with default value of 1 so this could be simplifyed.

Steps To Reproduce

Use promotTransaction() without value for transfers, e.g.

iota.promoteTransaction(tail, depth, minWeightMagnitude)

Expected behaviour

´transfersshould be initialized with a default spamtransfer` array of length 1.

Actual behavior

An error is thrown.

Errors

Unhandled rejection TypeError: Cannot read property 'address' of undefined
    at [...]/node_modules/@iota/core/out/core/src/createPromoteTransaction.js:131:50
    at tryCatcher ([...]/node_modules/bluebird/js/release/util.js:16:23)
    at Promise._settlePromiseFromHandler ([...]/node_modules/bluebird/js/release/promise.js:512:31)
    at Promise._settlePromise ([...]/node_modules/bluebird/js/release/promise.js:569:18)
    at Promise._settlePromise0 ([...]/node_modules/bluebird/js/release/promise.js:614:10)
    at Promise._settlePromises ([...]/node_modules/bluebird/js/release/promise.js:694:18)
    at _drainQueueStep ([...]/node_modules/bluebird/js/release/async.js:138:12)
    at _drainQueue ([...]/node_modules/bluebird/js/release/async.js:131:9)
    at Async._drainQueues ([...]/node_modules/bluebird/js/release/async.js:147:5)
    at Immediate.Async.drainQueues [as _onImmediate] ([...]/node_modules/bluebird/js/release/async.js:17:14)
    at runCallback (timers.js:694:18)
    at tryOnImmediate (timers.js:665:5)
    at processImmediate (timers.js:647:5)
chrisdukakis commented 5 years ago

Hi @pph7 , thank you for finding this issue. I pull requested a fix in #306.

For now I didn't modify the type of spamTransfers argument yet, because we should explore possibility of promoting with regular transfers as well. Most likely we will create an auto-promotion/reattachment function which emits transaction trytes to be attached.

pph7 commented 5 years ago

I am glad if I can help