View Issue Details

IDProjectCategoryView StatusLast Update
0006363Talermechant backendpublic2023-09-23 15:09
ReporterFlorian Dold Assigned ToChristian Grothoff  
PriorityhighSeverityfeatureReproducibilityhave not tried
Status closedResolutionfixed 
Target Version0.9.3Fixed in Version0.9.3 
Summary0006363: allow merchants to query more information about the deposit status
DescriptionQuoting 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.
TagsNo tags attached.

Relationships

related to 0006992 closedAntoine A need new "generic-credit" facade 

Activities

Christian Grothoff

2020-07-06 11:00

manager   ~0016388

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.

Christian Grothoff

2021-05-09 13:48

manager   ~0017804

DD13 will include the required wire API changes (as we need to change the wire API for DD13 anyway).

Christian Grothoff

2021-05-09 19:45

manager   ~0017805

Discussed with Florian: wire API should NOT be used for this, but a separate libEuFin facade created.

Christian Grothoff

2022-12-20 23:23

manager   ~0019527

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...

Christian Grothoff

2023-04-10 13:25

manager   ~0020047

Marcello (correctly) suggests to try to get this working using the Anastasis facade first.

Christian Grothoff

2023-04-12 15:12

manager   ~0020079

taler-merchant-wirewatch skeleton now exists. Todo: parse subject line, persist progress in new DB table, add man-page + test.

Christian Grothoff

2023-04-12 16:10

manager   ~0020080

Parsing, persisting and man-page are done. Testing is left.

Christian Grothoff

2023-04-13 19:29

manager   ~0020089

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!

MS

2023-04-14 17:16

reporter   ~0020095

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.

Christian Grothoff

2023-04-16 10:54

manager   ~0020096

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!

Christian Grothoff

2023-04-16 11:34

manager   ~0020097

With the very latest wallet, the withdraw step fails (wallet regression). => Assigning to Florian.

Florian Dold

2023-04-17 14:10

manager   ~0020104

According to what MS said on the phone, the issue was with how that wallet was used. And that invocation should be fixed now.

Christian Grothoff

2023-04-23 17:52

manager   ~0020131

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)

Christian Grothoff

2023-04-23 17:53

manager   ~0020132

MERCHANT_WIRE_TRANSFER_CONFIRMED and MERCHANT_ACCOUNTS_CHANGED added to GANA as new event types for this.

Christian Grothoff

2023-04-23 20:25

manager   ~0020134

31e5e07..dba2b83 documents the API change to allow user to configure taler-merchant-wirewatch per instance.

Christian Grothoff

2023-04-23 23:06

manager   ~0020135

Credentials and progress tracking are now stored in merchant backend together with accounts. Missing is moving the merchant-exchange interaction into a separate helper.

sebasjm

2023-04-26 19:21

developer   ~0020164

pushed 9df2547cc..03d3cce82

need an updated merchant to test it out

Christian Grothoff

2023-05-04 10:51

manager   ~0020173

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.

Issue History

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