Timeout before TX receipt has been received

[Karol-colony]

Steps to reproduce

1. Example: log in with a MetaMask wallet (I recommend mainnet)
2. Create 10 tasks with a budget
3. Finalize tasks at a cheapest rate, try to do this in short period of time like 15 min
4. Compare metamask transaction with list of task, look up for tasks which were finalized (it has to be visible on etherscan) but still are displayed as open

Expected behaviour

• When task is finalized and metamask transaction has been received, task should be marked as complete

Actual behaviour

• There are times when cheapest transaction (which were successfuly paid with metamask) are not reflected as completed on task UI

Suggestions (optional)

• I suggest to look up for such behaviour on mainnet. Please check if amount of tokens (budget) has changed despite payment was received.

Note: this can be problematic as user might be misleaded to pay twice. Please create separate issue to solve this issue after the investigative task is complete.

[rdig]

@auryn-macmillan and @Karol-colony please let me know of any tasks that are in this state so I can (at least) manually close them from the server side.

[rdig]

In order to properly fix this we need a cron-like service on the server side that checks for when the tx has actually been mined.

The gist of the change is to put the task in a "Payment Pending" state on the app side, then, on the server side, periodically check when that tx has been mined and update the database entries to reflect. (basically we need the resulting potId from that transaction receipt)

Since this quite a major change (code-wise at least) I want to pull both you @collinvine and @chmanie in for a quick chat around this.

Let me know when you have time, as I want to start on this properly as soon as I can.

[rdig]

A quick stop-gap solution for this could be:

Still keep the TX checking logic on the app side, but have an intermediate step as well:

• Send the payment tx
• Put the task in a pending state
• When the TX is mined, put the task in the completed state

All of the above happening on the server side.

This approach has the advantage of stopping a task being payed multiple times and gives us some breathing room in order to develop a "proper" solution, the one I've mentioned above.