-
Notifications
You must be signed in to change notification settings - Fork 5k
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
Block.timestamp in UNIX nanoseconds outputBlockFormatter in 1.2.6 (quorum, RAFT) #3442
Comments
Hi @VladoDemcak There's recurring discussion (ex: #3224) about how to support this for 1.x ... the main problem is that it would be a breaking change to reformat the timestamp Historically, the way platforms with special requirements like this have managed is by using Web3's Do you think that would work for your case?
1.x is the project's current focus and will be receiving the lion's share of regular bug fixes and improvements for the near term. |
Thanks! We checked Is it somehow possible to override the |
@VladoDemcak Ah, it looks like jpmorganchase/quorum.js deals with that part here and here. Out of curiosity, is their extension for Quorum/RAFT not suitable for your purposes? |
@cgewecke For example, simple thing like
But the I will try to explain my problem in more detail. What we are trying to do is very simple So I have:
The tx is mined correctly and we can see the new block with the tx on ledger. But within "send step" the web3js is trying to do some confirmation or something (still investigating what is happening). The I understand the fix will break some functionality in web3 however we would need to find a way how to make "RAFT + quorum + WSProvider + sendSignedTransaction" work. |
Wasn't aware of this deprecation notice in the docs, thanks for noting. It's not correct. HTTP is the most robust/reliable connection atm and will continue to be fully supported. Confirmations polling over HTTP should work correctly as of Web3 1.2.2. Will look further at what can be done for WS though...subscriptions seems less well supported by extend than it should be. |
Ok! This might change our approach and design. So let's assume we will use HTTP provider for But unfortunately, we want to have an event listener - I tried the event listener in Are we able to have event listen for |
@VladoDemcak With HTTP you can use getPastEvents. To reproduce the effect of subscription you'd need to call it within a block polling loop you write yourself, so it's a little more complicated.
Yes, that should be fine. They're separate connections and you'd have separate contract instances for each as well. |
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment, otherwise this issue will be closed in 7 days |
We are using quorum with RAFT consensus. Once a block is mined the blockchain returns the block with
timestamp
in UNIX format with nanoseconds.Example:
block.timestamp
is "0x16015c8446c19c16" (decimal: "1585650267003657238", GMT: Tuesday, March 31, 2020 10:24:27.003 AM**)#2791 has the fix for the problem and it has been merged into
1.0
.However in
1.x
(as well as in the latest release1.2.6
) there is stillutils.hexToNumber(block.timestamp);
which fails for our setup.https://github.com/ethereum/web3.js/blob/f9344d894866cbf64d67b49106b9b80562835af2/packages/web3-core-helpers/src/formatters.js#L295-L301
The #3070 (also referenced in #2791) has "Lower priority" issues - especially #1905 which is sadly still unchecked and still not merged in 1.2.6 (and
1.x
).My questions:
block.timestamp
in 1.2.6 in near future?block.timestamp
fix. Do you have any date when you will release 1.3.0?(if needed I can prepare steps to reproduce but it looks like the issue is well know but with low priority)
The text was updated successfully, but these errors were encountered: