View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006363 | Taler | merchant backend | public | 2020-06-03 13:31 | 2023-09-23 15:09 |
| Reporter | Florian Dold | Assigned To | Christian Grothoff | ||
| Priority | high | Severity | feature | Reproducibility | have not tried |
| Status | closed | Resolution | fixed | ||
| Target Version | 0.9.3 | Fixed in Version | 0.9.3 | ||
| Summary | 0006363: allow merchants to query more information about the deposit status | ||||
| Description | Quoting from the e-mail discussion: >> I'm not really sure what to do there in practice, as "Taler 1.0" doesn't >> really have any way for the merchant to ask about the status of the >> transfer other than trying to call the exchange. >> > > Well, we do have: > > https://docs.taler.net/core/api-exchange.html#get--deposits-$H_WIRE-$MERCHANT_PUB-$H_CONTRACT_TERMS-$COIN_PUB > > We could easily add a HTTP "Failed Dependency" status code to the API > here and define a message format to indicate details about the problem > to the merchant (and prescribe resolution strategies). > > This would mostly require another taler-exchange-XXX process to _query_ > LibEuFin for R-transactions, *and* a change to the exchange DB schema. > More messy: this will require additional changes to the merchant > backend. Please file a bug on this on Mantis, but I think we should > target Taler v1.5 for this, given the scope of the changes and need for > testing -- and the hopefully reasonably low likelihood of occurrence. At > least I think we should be fine to manually handle the first generation > of complaints for R-transactions, and that might even be better than > trying to automate a process where we may not fully understand all the > ways these things fail in practice. | ||||
| Tags | No tags attached. | ||||
|
|
Some status information is now provided ('wired'), alas automatically querying LibEuFin for transactions as _merchant_ is missing: right now, the merchant has to manually POST incoming transactions to the backend. Writing a taler-merchant-wirewatch tool should be done, but later. |
|
|
DD13 will include the required wire API changes (as we need to change the wire API for DD13 anyway). |
|
|
Discussed with Florian: wire API should NOT be used for this, but a separate libEuFin facade created. |
|
|
Marcello: can we please semi-urgently discuss this? I think this would be very good for Basel, and if you can _easily_ add the facade (which I would expect), I could likely get Priscilla to do the merchant backend legwork in January... |
|
|
Marcello (correctly) suggests to try to get this working using the Anastasis facade first. |
|
|
taler-merchant-wirewatch skeleton now exists. Todo: parse subject line, persist progress in new DB table, add man-page + test. |
|
|
Parsing, persisting and man-page are done. Testing is left. |
|
|
src/testing/test_merchant_wirewatch.sh is now a new test for this feature. However, it currently fails with a 500 internal server error from libeufin. 1) obviously we shouldn't ever fail with 500, so that should be fixed, _maybe_ a 502 is appropriate. So first the HTTP status should probably be fixed. 2) I do not understand _why_ we fail (what is wrong with the setup/script). Marcello: could you please look into both of these soon? Thanks! |
|
|
The error is from Nexus alone, _before_ even reaching the bank: the 502 error would not apply in this case. That's the response along the 500 status: { "code" : 9000, "hint" : "nexus error, see detail", "detail" : "EBICS (outgoing) document is invalid" } That happens because the EBICS document it is sending to the bank has one invalid value, which is the EBICS partner ID (in this case). The log below from libeufin-nexus-stderr.log shows the details: 16:55:23.343 [eventLoopGroupProxy-4-1] WARN tech.libeufin.util - Validation failed: org.x ml.sax.SAXParseException; lineNumber: 1; columnNumber: 235; cvc-pattern-valid: Value '{gnu net_partner}' is not facet-valid with respect to pattern '[a-zA-Z0-9,=]{1,35}' for type 'P artnerIDType'. 16:55:23.349 [eventLoopGroupProxy-4-1] ERROR tech.libeufin.nexus - Caught exception while handling '/bank-connections/gnunet-connection/connect (EBICS (outgoing) document is invali d (HTTP status 500 Internal Server Error)) Try to adjust the value in "--partner-id" in the CLI's "new-ebicssubscriber" subcommand to one that matches the pattern shown above in the logs. |
|
|
After your fix, it still doesn't work: the facade doesn't return the transaction! I've tried adding an explicit fetch-transactions in addition to the existing "sleep 3", but neither seems to make the transfer show up in the facade!? Please help! |
|
|
With the very latest wallet, the withdraw step fails (wallet regression). => Assigning to Florian. |
|
|
According to what MS said on the phone, the issue was with how that wallet was used. And that invocation should be fixed now. |
|
|
Design discussion: - configuration for taler-merchant-wirewatch should entirely move into the database - tmw should NOT use the REST API (no credentials!) - tmw should support multiple instances (from one process) - merchant-exchange interaction for transfers should be moved into a separate helper process (triggered by NOTIFY) |
|
|
MERCHANT_WIRE_TRANSFER_CONFIRMED and MERCHANT_ACCOUNTS_CHANGED added to GANA as new event types for this. |
|
|
31e5e07..dba2b83 documents the API change to allow user to configure taler-merchant-wirewatch per instance. |
|
|
Credentials and progress tracking are now stored in merchant backend together with accounts. Missing is moving the merchant-exchange interaction into a separate helper. |
|
|
pushed 9df2547cc..03d3cce82 need an updated merchant to test it out |
|
|
6396057..9316c05 should fix taler-merchant-exchange and removes now dead logic from the POST /transfers endpoint. Assuming the SPA can handle the 204 instead of the 200 for the POST /transfers endpoint (reported separately on mattermost), this should fix "everything" for this bug. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2020-06-03 13:31 | Florian Dold | New Issue | |
| 2020-06-03 13:31 | Florian Dold | Status | new => assigned |
| 2020-06-03 13:31 | Florian Dold | Assigned To | => Christian Grothoff |
| 2020-07-06 11:00 | Christian Grothoff | Note Added: 0016388 | |
| 2020-07-06 11:00 | Christian Grothoff | Assigned To | Christian Grothoff => |
| 2020-07-06 11:00 | Christian Grothoff | Status | assigned => confirmed |
| 2020-07-16 15:16 | Christian Grothoff | Severity | minor => feature |
| 2020-12-20 20:29 | Christian Grothoff | Category | exchange => mechant backend |
| 2020-12-26 17:16 | Christian Grothoff | Assigned To | => Christian Grothoff |
| 2020-12-26 17:16 | Christian Grothoff | Status | confirmed => assigned |
| 2021-01-30 23:58 | Christian Grothoff | Status | assigned => confirmed |
| 2021-01-30 23:58 | Christian Grothoff | Assigned To | Christian Grothoff => |
| 2021-04-19 19:10 | Christian Grothoff | Assigned To | => Christian Grothoff |
| 2021-04-19 19:10 | Christian Grothoff | Status | confirmed => assigned |
| 2021-05-09 13:48 | Christian Grothoff | Note Added: 0017804 | |
| 2021-05-09 19:45 | Christian Grothoff | Note Added: 0017805 | |
| 2021-07-13 06:48 | Christian Grothoff | Assigned To | Christian Grothoff => |
| 2021-07-13 06:48 | Christian Grothoff | Status | assigned => confirmed |
| 2022-12-20 23:22 | Christian Grothoff | Assigned To | => Christian Grothoff |
| 2022-12-20 23:22 | Christian Grothoff | Status | confirmed => assigned |
| 2022-12-20 23:23 | Christian Grothoff | Note Added: 0019527 | |
| 2022-12-20 23:24 | Christian Grothoff | Target Version | => 0.9.2 |
| 2023-02-17 17:50 | Florian Dold | Target Version | 0.9.2 => 0.9.3 |
| 2023-04-09 23:13 | Christian Grothoff | Priority | normal => high |
| 2023-04-10 13:25 | Christian Grothoff | Note Added: 0020047 | |
| 2023-04-12 15:12 | Christian Grothoff | Note Added: 0020079 | |
| 2023-04-12 16:10 | Christian Grothoff | Note Added: 0020080 | |
| 2023-04-13 19:29 | Christian Grothoff | Note Added: 0020089 | |
| 2023-04-13 19:29 | Christian Grothoff | Assigned To | Christian Grothoff => MS |
| 2023-04-13 20:43 | Christian Grothoff | Relationship added | related to 0006992 |
| 2023-04-14 17:16 | MS | Note Added: 0020095 | |
| 2023-04-16 10:54 | Christian Grothoff | Note Added: 0020096 | |
| 2023-04-16 11:33 | Christian Grothoff | Assigned To | MS => Florian Dold |
| 2023-04-16 11:34 | Christian Grothoff | Note Added: 0020097 | |
| 2023-04-17 14:10 | Florian Dold | Note Added: 0020104 | |
| 2023-04-17 14:10 | Florian Dold | Assigned To | Florian Dold => Christian Grothoff |
| 2023-04-23 17:52 | Christian Grothoff | Note Added: 0020131 | |
| 2023-04-23 17:53 | Christian Grothoff | Note Added: 0020132 | |
| 2023-04-23 20:25 | Christian Grothoff | Note Added: 0020134 | |
| 2023-04-23 23:06 | Christian Grothoff | Note Added: 0020135 | |
| 2023-04-26 19:21 | sebasjm | Note Added: 0020164 | |
| 2023-04-26 19:21 | sebasjm | Status | assigned => feedback |
| 2023-05-04 10:51 | Christian Grothoff | Note Added: 0020173 | |
| 2023-05-04 10:52 | Christian Grothoff | Status | feedback => resolved |
| 2023-05-04 10:52 | Christian Grothoff | Resolution | open => fixed |
| 2023-05-04 10:52 | Christian Grothoff | Fixed in Version | => 0.9.3 |
| 2023-09-23 15:09 | Christian Grothoff | Status | resolved => closed |
| 2025-03-22 14:09 | Christian Grothoff | Category | mechant backend => merchant backend |
