View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0010813 | Taler | deployment and operations | public | 2025-12-19 04:45 | 2026-02-04 19:00 |
| Reporter | vecirex | Assigned To | Christian Grothoff | Resolution deadline | |
| Implementer | Reviewer | ||||
| Release signed by | Deployed by | ||||
| Verifier | Communicator | ||||
| Data protection authority notification required | No | ||||
| CSIRT notification required | No | ||||
| Estimated effort (hours) | Actual effort (hours) | 0 | |||
| Fast-track | No | ||||
| Work package | none | ||||
| Priority | high | Severity | tweak | Reproducibility | have not tried |
| Status | closed | Resolution | duplicate | ||
| Product Version | git (master) | ||||
| Target Version | 1.4 | Fixed in Version | 1.4 | ||
| Summary | 0010813: check my.taler-ops.ch logs: kyc status took many hours to get updated | ||||
| Description | The instance talersticker (used for demo and Taler sticker gift purposes) running at my.taler-ops.ch was successfully KYCed with a PF IBAN no. after like 1d given SEPA delays we cannot control and it was possible to go for the last step in KYC: accepting the exchange terms, for an exchange run by Taler Operations AG (TOPS). This worked and I could receive payments at any time, but unfortunately "KYC Status" sticked in the menu, appearing (as always when it's there) as an orange button. Clicking on it showed the usual text to either send a tiny amount to verify the IBAN no. or to go for step 2 of KYCing an IBAN account, which is the state described in line 1 of the descr here and we did successfully, even it was never shown as successful: for many hours, afternoon until late evening or maybe even after midnight. There *might* be a way to "solve" such situations, which is by manually carrying out the following command; that's, of course, only possible by Taler Merchant operators: taler-merchant-kyccheck -t In any case, UX-wise we've a problem. | ||||
| Steps To Reproduce | It's not clear, if it's reproducible, but as I also need to do tests & analysis on using twice the same IBAN number and seeing if you can reclaim your IBAN after removing the IBAN account or deleting or even purging your instance, this can then be said. | ||||
| Additional Information | Options to run taler-merchant-kyccheck look like this; and it's invoked by systemd to run as background by the taler-merchant-httpd.service: taler-merchant-kyccheck background process that checks the KYC state of our bank accounts at various exchanges Arguments mandatory for long options are also mandatory for short options. -c, --config=FILENAME use configuration file FILENAME -h, --help print this help -L, --log=LOGLEVEL configure logging to use LOGLEVEL -l, --logfile=FILENAME configure logging to write logs to FILENAME -T, --timetravel=[+/-]MICROSECONDS modify system time by given offset (for debugging/testing only) -t, --test run in test mode and exit when idle -v, --version print the version number | ||||
| Tags | No tags attached. | ||||
| The issue is already described in 0010627; this ticket is a todo > 5mins to see if I can see better what's going on, now also understanding better those components than back then. | |
| The latest code now *automatically* triggers taler-merchant-kyccheck if a user views the KYC status in the SPA and thus the SPA makes a request to /kyc. Whenever the SPA re-news the long-poller, we will also again ensure that we are long-polling with the exchange. Might be excessive, but at least this should make sure the data is always super up-to-date --- at least once the SPA implements the new long-polling. | |
| I think this is completely a duplicate of 0010627. | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2025-12-19 04:45 | vecirex | New Issue | |
| 2025-12-19 04:46 | vecirex | Assigned To | => vecirex |
| 2025-12-19 04:46 | vecirex | Status | new => acknowledged |
| 2025-12-19 04:50 | vecirex | Description Updated | |
| 2025-12-19 04:50 | vecirex | Additional Information Updated | |
| 2025-12-19 05:02 | vecirex | Relationship added | related to 0010623 |
| 2025-12-19 05:02 | vecirex | Relationship deleted | related to 0010623 |
| 2025-12-19 05:05 | vecirex | Relationship added | related to 0010627 |
| 2025-12-19 05:07 | vecirex | Note Added: 0027122 | |
| 2026-01-25 06:52 | Christian Grothoff | Assigned To | vecirex => Christian Grothoff |
| 2026-01-25 06:52 | Christian Grothoff | Status | acknowledged => assigned |
| 2026-01-25 11:26 | Christian Grothoff | Note Added: 0027338 | |
| 2026-01-25 11:29 | Christian Grothoff | Status | assigned => informing |
| 2026-01-25 11:29 | Christian Grothoff | Resolution | open => duplicate |
| 2026-01-25 11:29 | Christian Grothoff | Fixed in Version | => 1.5 |
| 2026-01-25 11:29 | Christian Grothoff | Note Added: 0027340 | |
| 2026-01-25 11:29 | Christian Grothoff | Relationship replaced | duplicate of 0010627 |
| 2026-01-25 11:29 | Christian Grothoff | Product Version | => git (master) |
| 2026-01-25 11:29 | Christian Grothoff | Target Version | => 1.5 |
| 2026-01-28 07:47 | Christian Grothoff | Fixed in Version | 1.5 => 1.4 |
| 2026-01-28 07:47 | Christian Grothoff | Target Version | 1.5 => 1.4 |
| 2026-02-04 19:00 | Christian Grothoff | Status | informing => closed |