-
Notifications
You must be signed in to change notification settings - Fork 92
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ChainID hash / ChainID Commit Hash random in pending-entries
response
#1004
Comments
pending-entries
responsepending-entries
response
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) 2. entry reveal / chain reveal IMO, no need to return chain commit hash as chainID, it's inconsistent and misleading. |
There are some applications that depend on |
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. |
I noticed, that
pending-entries
response returns unexpected hashes.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
The text was updated successfully, but these errors were encountered: