Ack timeout

[eolszewski]

Seems like the cli isn't talking to my local running node... here's the related branch of the repo I'm working with.

Note: I am really only using factom.js, located here

You will need to create a .env file with the following defined:

FACTOM_PK=
FACTOM_SK=
EC_PK=
EC_SK=

You can run this with the following commands:

npm i
docker-compose up -d
node factom.js

I see nothing on the factom local network side of things as this executes and don't get any acks back from the network :/

(node:11704) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 1): Ack timeout
(node:11704) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

This would indicate something wrong in the way that I setup the network, how I'm connecting to it with this lib, or how I'm calling it with this lib - any assistance is greatly appreciated.

[eolszewski]

@PaulBernier, @AlexCarrithers?

[PaulBernier]

@eolszewski I replied on Discord:

@Eric so I gave it a try, and get the same result as @archaeopteryx , which seems like a reasonable result. The first time I execute it, it does everything but fail at the getEntries(), because you have to wait for the block to be finished first (which in simulation is after 6s I believe) I don't get any ack timeout, unless I run again the factom.js script, which try to recreate the same entries as during at the first execution, and the network doesn't accept that

[eolszewski]

@PaulBernier am i supposed to be seeing logs from factomd from the result of these operations?

Just wondering because I get the same result but see nothing in the console window which is running factomd

[eolszewski]

Also, I'm always getting entries like this retrieved from Factom:

Entry {
    chainId: <Buffer bf 5d 3a ff b7 3e fd 2e c6 c3 6a d3 11 2d d9 33 ef ed 63 c4 e1 cb ff cf a8 8e 27 59 c1 44 f2 d8>,
    content: <Buffer 32 36>,
    timestamp: undefined,
    extIds: [ <Buffer 7a> ],
    blockContext: undefined } ]

where the timestamp and blockContext is undefined - is this expected behavior on the local network / is this a bug in my code?

[PaulBernier]

It's normal you don't see see anything in factomd logs. Now I think there is some verbose flags that may show those but I'm not familiar with it, we would have to ask someone from Factom Inc.

Yes it's normal, when querying directly an entry by its hash you don't have the block context (and the timestamp, because timestamp can only be deducted from block context, it is not stored in the entry itself). The only way to have a block context of an entry is to rewind the chain it is part of, which is an expensive operation. The lib offers a method getEntryWithBlockContext to do that, but again you have to be aware that behind the hood it is rewinding the whole chain of the entry to find the block context.

[eolszewski]

Got it, thanks!