Does the Sprint2 have a delay?
You’re experiencing problems with the operation of Delegation Harvesting, right?
(As I have long feared).
This is an issue with the SDK.
The Desktop wallet release should also be delayed.
Does the Sprint2 have a delay?
You’re experiencing problems with the operation of Delegation Harvesting, right?
(As I have long feared).
This is an issue with the SDK.
The Desktop wallet release should also be delayed.
No it does not have a delay. Release is 9th Nov (UTC time). It is still planned for today.
The team have tested delegated harvesting and it appears to be working. There is an issue with displaying the status which will be looked at in next sprint. Activation is working though.
I believe that issue with SDK has been fixed already, the status issue is one with rest which they have a plan for, it just didnt make this build.
Can you confirm what is the issue is with the SDK and has it been logged on github?
I think it is probably one of these:
https://github.com/nemtech/symbol-sdk-typescript-javascript/pull/710 This one fixed the unlocked_account issue for delegated harvesting,
https://github.com/nemtech/symbol-sdk-typescript-javascript/pull/709 this one is the message bug. (Issue: https://github.com/nemtech/symbol-sdk-typescript-javascript/issues/704)
Thanks DaveH for explanation. I really like how you simplify things when making reply
Did you check the operation?
Make sure it works.
We don’t want you to release something that doesn’t work.
To begin with, delegated harvesting takes time.
Did you make sure it really works?
GodTanu, have you tested the new wallet release first before asking such questions?
Of course.
Have you tested it?
Please address to me if the delegated harvest works.
Delegated harvesting may not be working for me either.
If it doesn’t work, then, I want them to release something that works correctly. This release was a concern for the future.
All of the releases before the 16th of November are interim releases, they are the release from an Agile Sprint, so are not intended to be fully functional, fully tested releases. HOWEVER, yes they are tested within the development environment and when we say something is working, it is working and has been tested in the development environment.
Releasing in this way is intended to achieve the below things (mainly):
On this release I personally activated delegated harvesting on a profile via the nightly build wallet and it looked to have activated, but I have not yet harvested anything after 12 hours either.
From the comments above and what I have seen on Twitter so far this morning (all the testing you have been doing in Japan is overnight in Europe) there are potentially some issue which I will speak to the team about in the next few hours and will communicate back what is happening.
I will try and update by 14:00 UTC 9th Nov, probably sooner but I want to give chance to look at what is going on calmly before we work out next steps.
In conclusion, there is not work delegated harvesting on this Desktop wallet.
The cause has already been identified Japanese community.
We are waiting for message bug(#704) to be addressed.
Catapult server 0.10.0.4 is also expected to be released soon, so we’ll wait.
Thanks @GodTanu correct that issue is as identified and worked through by Japanese community, thank you for the hard work on this one.
There are a couple of other problems though which also need to fixed and there is a way to do this in a patched release, I will post more completely in a short while, I am just asking the devs to check the post to ensure it is accurate
Apologies the update is a little later than planned, it took a couple hours longer than I thought to get it all written up.
We have now worked through the issues with the interim release of the Desktop Wallet last night (0.13.3).
There are workarounds and a patched release of the Dekstop Wallet is targetting 11th Nov in the morning UTC; SUBJECT TO TESTING .
There are two main issues:
Wallet is using Alpha builds of the SDK - there was the Endian/Marker issue in an SDK call which was worked around on a dev workstation but not included in the Alpha, as per @GodTanu’s comment above
The public keys/certificates being used for enabling delegated harvesting have an issue, it was not present in the dev environment due to things being run locally so not being an issue
Unfortunately both of the above were not evident in the development environment due to workarounds that then became evident on Testnet. We have learned why and are putting some separate testing in place to try and avoid this in future Sprint Releases.
The good news is that these two issues can be resolved in the SDK and released as a new Alpha version of the SDK inside a patched wallet build. That is being worked on right now and will be released when tested.
The patched release is likely to be tomorrow morning (11th Nov morning UTC) subject to testing.
There are some further minor issues which hide the above due to not being able to easily access the active harvesting status of a node, these will require some changes to REST Gateway which will be included in the next Testnet patch along with the next server version (0.10.0.4)
There are 2 major issues and 2 minor ones.
GodTanu + TomoTomo9696:
https://twitter.com/GodTanu2/status/1326054923411222529
https://gist.github.com/tomotomo9696/44a4bb7ee6b0749327695605a9aa98b2
Java:
https://github.com/nemtech/symbol-sdk-java/issues/362 .
JS/TS:
https://github.com/nemtech/symbol-sdk-typescript-javascript/issues/704 & https://github.com/nemtech/symbol-sdk-typescript-javascript/issues/713
This issue can be fixed in the SDK with an Alpha build and a PR has already been created for review.
Each node has a certificate, which is generated from a public key. This is the key that is used in the linking transaction for harvesting. There is no REST endpoint to retun the public key + cert at present, the docs incorrectly stated one did exist via NodeInfo, but that is returning the certificate authority cert not the node cert. The docs are being fixed and reviewed.
This causes a problem with trying to activate from the desktop wallet because the linking transaction can’t be called reliably. It wasn’t an issue in the development environments because they utilise local certs and known public keys so became evident when using Testnet which only happened on release.
Short term fix: There are several known NGL nodes which are set up and working, the short term fix is going to be to restrict the node selection to a drop down list of nodes that we know should work, the next wallet tagged wallet release will contain this workaround. There is a risk that the slots on he known nodes fill up obviously but we will try and increase those numbers and keep an eye where possible, doing this will get some delegated harvesting going on Testnet more widely. This fix has been made in a development environment is being tested at present.
Mid-longer term: Will be fixed in the next Rest + Server release and then worked into the Wallet to allow selection of any node, a more configurable form will also be provided to allow provision of the hostname and public key explicitly for any node that is not discoverable via the rest endpoint.
There is a weakness at present with getting the active status of harvesting on a node due to how some communications between REST gateway and Peer node work around the diagnostic call, this was the 2/2 that was highlighted in the release note and is planned for the next sprint, which will be released in the next Server + REST release (Testnet patch).
This makes it hard to display to a wallet user what the reliable active status is.
This is being tracked under: https://github.com/nemtech/symbol-sdk-typescript-javascript/issues/705
This was part of the 2/2 comment in the release note and planned to be released in the next sprint already.
The current way of querying the harvesting history is inefficient but is functional, this will be altered to make it easier to get full harvesting history by account in the next Server + REST release (Testnet patch). This was part of the 2/2 comment in the release note and planned to be released in the next sprint already.
Short term it is possible to see this on the account using Explorer or on the Wallet as you see from TomoTomo9696 here: https://twitter.com/tomotomo_9696/status/1326101606266408960 (edited)
NGL should organize & manage Github Issue.
There are many neglected issues. Unable to identify current issues.
Please clarify the known issues.
If there is a shortage of administrators, hire new ones.
The NGL should have enough money to pay for it.
Thanks, this is not a priority for the current sprint delivery. It is on the list as part of the clean up work at the end of the delivery
The team are addressing issues related to the features they are working on in the sprints and updating Github
If there is a specific issue you are concerned about, rather than a general feedback, please put the link up here and I’ll take a look
There is no answer to my issue either.
“Symbol is primed to facilitate tokenization and STO issuance”
But we can’t even examine the library.
How is the whiskey case going?
An updated version has now been released with patches for these issues and enables delegated harvesting.
The question that arises for me:
Too much work for too few developers?
(Documentation included)
And by that I don’t just mean the evolution of wallets …
thx
Previously, I signed up for the mobile version test via the google form to participate. I haven’t heard from them since. What happened to it?
When is Account and Mosaic Restriction going to be implemented?
In the final release?