View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004434 | Taler | deployment and operations | public | 2016-04-17 12:30 | 2016-05-04 09:32 |
| Reporter | Christian Grothoff | Assigned To | Florian Dold | ||
| Priority | urgent | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Platform | i7 | OS | Debian GNU/Linux | OS Version | squeeze |
| Product Version | 0.0 | ||||
| Target Version | 0.0 | Fixed in Version | 0.0 | ||
| Summary | 0004434: fulfillment page only works on reload | ||||
| Description | Using my local installation of the Git code (with the unstable wallet), the fulfillment page for both shop and blog does not fully work; it requires me to press F5/reload, and then the pages does show up properly. For blog pages that I already did pay for, it works instantly as expected. | ||||
| Tags | No tags attached. | ||||
|
|
I'm struggling to reproduce this, since on shop.test.taler.net there's 0004433, so payment simply hangs, always ... |
|
|
Now that the test deployment works again, I'm still unable to reproduce this. For me, with the unstable webstore wallet and the test depoyment, the (non-blank) fulfillment shows instantly. |
|
|
Let's get to the bottom of this once I'm back, unless I figure it out first ;-). |
|
|
Might be related to 0004475, not 100% sure though. Could it be possible that you didn't reset your wallet before it happened, and it contained other denomination keys that were not in the /keys of your local exchange? |
|
|
I asked Ben to try the demo, and the issue popped up again. Looking at the logs, it seems like it only occurs when the merchant has to contact the exchange for /keys. A hacky "fix" would be to refresh the fulfilment site periodically when waiting for the merchant, so this issue will never surface. We should still fix the underlying problem ... Unfortunately the logs didn't surface any problems, and Ben wasn't able to reproduce the problem. |
|
|
This is now "fixed" in web-common:06af7ad in the sense that a user will never observe this behaviour, since we will retry payment after the HTTP request times out with truncated exponential back-off. The underlying bug(s) in the merchant backend are probably still there though ... |
|
|
Ok, are you creating a log whenever this happens, so that we can reasonably find & fix the underlying issue? Also, is there an open bug on the merchant issue? |
|
|
Merchant bugs are 0004465 and 0004444. We don't have any telemetry in the wallet, there is no way to (persistently) log this. What do you have in mind there? Of course we log retries, but it's lost as soon as the page reloads ... |
|
|
Oh, logs don't have to persist on this, just if a dev does look he should easily see that a retry was done. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2016-04-17 12:30 | Christian Grothoff | New Issue | |
| 2016-04-17 12:30 | Christian Grothoff | Status | new => assigned |
| 2016-04-17 12:30 | Christian Grothoff | Assigned To | => Florian Dold |
| 2016-04-17 14:10 | Florian Dold | Note Added: 0010496 | |
| 2016-04-19 03:08 | Florian Dold | Note Added: 0010512 | |
| 2016-04-24 23:55 | Christian Grothoff | Note Added: 0010557 | |
| 2016-04-27 15:38 | Florian Dold | Note Added: 0010571 | |
| 2016-05-01 22:46 | Florian Dold | Note Added: 0010588 | |
| 2016-05-01 22:47 | Florian Dold | Status | assigned => confirmed |
| 2016-05-04 09:25 | Florian Dold | Note Added: 0010624 | |
| 2016-05-04 09:25 | Florian Dold | Status | confirmed => resolved |
| 2016-05-04 09:25 | Florian Dold | Resolution | open => fixed |
| 2016-05-04 09:26 | Christian Grothoff | Note Added: 0010625 | |
| 2016-05-04 09:29 | Florian Dold | Note Added: 0010626 | |
| 2016-05-04 09:30 | Christian Grothoff | Note Added: 0010627 | |
| 2016-05-04 09:32 | Christian Grothoff | Status | resolved => closed |
| 2016-05-04 09:32 | Christian Grothoff | Fixed in Version | => 0.0 |
