Open ilzheev opened 4 years ago
Besides this bug, from a user side I would like that pending entries API works with this logic:
1. entry commit (no reveal yet) / chain commit (no reveal yet)
Returns entryhash: XXXX, chainid: null
2. entry reveal / chain reveal
Returns entryhash: XXXX, chainid: XXXX
IMO, no need to return chain commit hash as chainID, it's inconsistent and misleading. What do you think about this logic?
There are some applications that depend on pending-entries
(mainly FAT), so I think it would make sense to add a new API call (maybe just pending
), which returns data in a more accessible format and can also return things like transactions / admin block entries in addition to just entries.
How fixing API without changing request params and response format may hurt in this situation? The fix will bring only correct Chain IDs for chain reveals, rather than unusable random IDs right now.
How fixing API without changing request params and response format may hurt in this situation?
It's more along the lines of we don't know who is using the API and which parts of the data they're using, so introducing fixes that alter the data being returned has the potential of breaking those applications. In this case, I know that FAT is relying on pending entries in their syncing process and it's a possibility that might break. @AdamSLevy might be able to offer some insight on whether or not it would affect FAT.
I can make a branch that modifies the API for your use, @ilzheev. And if we can get some time from someone over at FAT we can verify that the fix either breaks them or not.
@PaulSnow @WhoSoup we're working at Kompendium on FAT codebase now, I can check this for you guys. FAT has some functionality based on pending entries, we can apply patch if required.
@PaulSnow @sigrlami thank you gentlemen. I don’t need a separate branch as Explorer is connected to Open Node (so I need the patch to be the part of future official factomd release, that will be installed on Open Node).
I noticed, that
pending-entries
response returns unexpected hashes.I created 10 chains with the following ChainIDs, making commit+reveal without delay at minute 1-2:
While checking
pending-entries
API response (multiple times at minutes 3-9), I saw all 10 entries objects, but 3 of them had Chain ID hash, and other 7 had Chain ID commit hash (sha256d of ChainID).The pending-entries API response (for this 10 created chains) was the same for several requests, that were made with minutes interval.
@carryforward @WhoSoup