Issues with the DAPP

General
#1

thanks agnostic for this message - I will copy it to the forum so that also the other developers can respond.

  1. Hm… yes I had this problem as well. Most likely it is a problem with the GETH node not resubmitting a transaction to the network if is somehow gets dropped. Anyway, we will keep an eye on it.

  2. This is only an interface issue. So the value field shows the amount of ether that was send with the transaction. In a buy transaction you send Ether so buy shares. I a sell transaction you only give the contract the information that you want to sell some shares (so you don’t send Ether in the original transaction). However - this transaction should trigger the contract to send some Ether to your account (the money you get for selling the shares) In the transaction you linked you can click on: “show all internal transactions” and you will find a transaction that sends your account 82 Finney - so it seems that you sold shares worth 82 Finney;

Bildschirmfoto 2015-10-18 um 19.16.35.png1043×595 99.1 KB

The refund field is only for gas costs. If your transaction sets an storage value of the contract to 0 some gas will be refunded.

  1. OK, thanks - we will fix it.

4 -6) Have to look into it later.

So no user funds are left in the contract at any time. The user only holds shares in the contact. However - in the new DAPP you have to use a light wallet - but you 100% control this and you can use this same light wallet (the 12 word seed) to log into other DAPPs that use the light wallet like this on: http://alpha.ujomusic.com and use your Ether on this address for this DAPP. Hopefully import and export of a lightwallet (seed) into the regular ether node/ client will be possible soon.

#2

Two more:

  1. If done quickly, it seems it’s possible to submit 2 “Sell Shares” orders for the same thing (of course only the first one completes).

  2. There’s a bug in JavaScript, when you select No (outcome) and then I Agree, as the password prompt pops up the No changes to Yes. At that point you don’t know whether you just wanted Yes or No.
    If you go ahead (enter password + Sell), after you’re done Yes will remain in the GUI which is very unsettling because you can’t undo the transaction anymore and it’s not possible to easily check how you just voted…

#3

Ok, thanks - we will check - I have an idea what 1) could be and 2) sounds like it is fixable easy.

#4

Another issue is when you want to sell shares and enter a whole number and increment up, it won’t go till the end.
For example if I have 10.5 shares and instead enter 8, then arrow up 3 times, it should stop at 10.50, but instead it stops at 10.

#5

On several occasions I noticed transactions take a very long time.
For example right now I have 2 pending transactions from 14 hours ago!

That’s not so much a problem in itself, but it is a problem if I want to sell those shares.
I can’t, because I paid, but I haven’t received the shares yet.

Timely and stable transaction execution is important.

#6

So the forwarding of transactions is mostly a geth thing and not directly part of our DAPP. However, if a transaction is pending for 14h it is most likely dropped from the network and I guss the mechanism of resubmitting the transaction are still not implemented.
What you can do it reload the page (maybe use an incognito window) I would expect that than you see the state before the transaction and you could send the same transaction again. Maybe @stefan_george now more about the reasons?

But thanks for reporting, this is really valuable to us!

#7

It’s these 2, still pending 24+ hours later and in the meantime event odds changed a lot.

I logged in Incognito Mode and was able to “again” sell the shares, so I probably “unnecessarily” lost a few ETH on this issue.

This is very confusing. If there’s already a transaction listed (e.g. Transactions (2)), with tx ID’s, that should mean there has been a transaction submitted to the network, not that there’s a plan to submit it to the network at some point in the future.

#8

I agree very much. And indeed that means that the transaction is already submitted to the network. Unfortunately at the current state of the Ethereum network (or more precisely the current state of the node implementations) this is no guarantee that the transaction will make it into the blockchain.

For more details read: https://github.com/ethereum/go-ethereum/issues/1878
We should check if we use the latest geth version on our server - I hope they have meanwhile fixed this problem.

By the way - if we would expect that this is an issue that will not be fixed by the geth client we would try to think of a solution on our side - since we expect that this will be solved soon by them we will most likely just wait for their solution.

1 Like
#9

Hi, I’m also having issues with transactions never resolving. One did get through, but most of them are not.

Also, if I pop open the conlsole I’m getting a security error:

Mixed Content: The page at 'https://groupgnosis.com/dapp/#/transactions' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint 'http://api.blockapps.net/eth/v1.0/transaction?address=[txAddr]&sortby=desc'. This request has been blocked; the content must be served over HTTPS.

Edit: Definitely some more weirdness going on.

Overally I made 3 transactions – one earlier this week when it was at 52% (#1), another one when Vitalik went on stage (#2), which got stuck at pending, and one that I tried to make again (#3). The latter two seemed to be stuck on pending.

When I checked again tonight the two seemed to be not pending anymore (as below)

Pasted image1214×268 54.9 KB

If you look at the actual transactions they seem to be… off. https://etherchain.org/account/0x817ffab110a444d99a201daed90bea765431814a#txsent

How is this even possible?

I only ever put 20 eth into the wallet, so how is it spending more than that?