View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0010811Talerexchangepublic2025-12-19 02:372026-02-26 23:40
Reportervecirex Assigned ToChristian Grothoff  
PriorityurgentSeveritymajorReproducibilityhave not tried
Status resolvedResolutionfixed 
Product Version1.3 
Target Version1.5Fixed in Version1.5 
Summary0010811: Test case: try to not use an IBAN anymore, deleting a bank account or the whole instance; can IBAN be reclaimed? [20min]
DescriptionIt's not tested in recent merchant versions (we will test v1.2.6+) if an IBAN can be reclaimed (as in: if an IBAN can be added to be KYCed again) by either deleting the bank account only or even deleting the instance.

As on talver.hacktivism.ch (TOPS/CHF testing) there are enough KYCed IBANs, both test cases can easily be covered.
Steps To Reproduce1. Login to a merchant instance which has a KYCed IBAN. Delete the IBAN under the bank account menu entry; try to readd it.
2. Login again. Say to delete the instance; try now to add the IBAN again.
(3. Dito. Say this time to purge the instance; dito.)

As what concerns 2. vs. 3.: 3. is the more radical approach, because it effectively deletes all the instance's data. Going for 3. makes sense if even 2. doesn't work, let's not expect this! :)
Tagscustomer

Relationships

related to 0010810 assignedFlorian Dold Test case: use an IBAN twice (context: TOPS/CHF) 
related to 0010974 resolvedFlorian Dold test needed for behavior of multiple KYC auth transfers [2h] 
related to 0010703 confirmed Test reusing same IBAN on new taler-merchant installation 
related to 0011069 assignedFlorian Dold need test & fix for multiple instances with same IBAN and KYC [2h] 

Activities

vecirex

2025-12-19 02:40

manager   ~0027119

Last edited: 2025-12-19 02:41

 Assigning to myself, then assigning to Florian (cf. ticket 0010810 for similar approach).

vecirex

2026-02-15 10:23

manager   ~0027731

Last edited: 2026-02-15 10:24

 @CG: Please relate this ticket to the other test case, so that we can test & close this (together), if this is the same issue as trying to use the very same IBAN twice for two different instances.

Christian Grothoff

2026-02-16 23:35

manager   ~0027765

I need a reproducer first.

Florian Dold

2026-02-23 20:49

manager   ~0027871

$ taler-harness run-integrationtests merchant-kyc-auth-multi

This currently fails due to an unexpected 204 No content response. Once that's fixed, the test should succeed though.

Christian Grothoff

2026-02-26 13:08

manager   ~0027909

After 780e0606b..9ab71001b the test *still* fails. To be investigated.

Christian Grothoff

2026-02-26 13:09

manager   ~0027910

The last response we see in the test is indeed a 204:


GET /instances/minst1/private/kyc?timeout_ms=30000&lpt=1 HTTP/1.1
Accept: application/json
Authorization: Bearer secret-token:NJ6EQYNR4AWDGKCAADDWM41PYKQBBR8K3ZQHJR9YHXT8GDA36KRG
Host: localhost:8083
Connection: keep-alive


HTTP/1.1 204 No Content
Date: Thu, 26 Feb 2026 12:08:43 GMT
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: *
Cache-Control: no-store
ETag: 0000000000000000000000000000000000000000000000000000

Christian Grothoff

2026-02-26 13:37

manager   ~0027911

The reason for the 204 is pretty clear from this sequence earlier:

GET /instances/minst1/private/accounts HTTP/1.1
Accept: application/json
Authorization: Bearer secret-token:NJ6EQYNR4AWDGKCAADDWM41PYKQBBR8K3ZQHJR9YHXT8GDA36KRG
Host: localhost:8083
Connection: keep-alive


HTTP/1.1 200 OK
Date: Thu, 26 Feb 2026 12:08:43 GMT
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: *
Cache-Control: no-store
Content-Type: application/json
Content-Length: 260

{
  "accounts": [
    {
      "active": true,
      "payto_uri": "payto://x-taler-bank/localhost/minst1?receiver-name=minst1",
      "h_wire": "RQBZ243D9M70BW3T7Z1QV02HRQ3D5J8DV96XQEB85Z2YWSS4A0CZ8XDH875AG52D68XQR76KDGSCX7YPZ5WJPWRGSF887RWQHRJNMB0"
    }
  ]
}
DELETE /instances/minst1/private/accounts/RQBZ243D9M70BW3T7Z1QV02HRQ3D5J8DV96XQEB85Z2YWSS4A0CZ8XDH875AG52D68XQR76KDGSCX7YPZ5WJPWRGSF887RWQHRJNMB0 HTTP/1.1
Accept: application/json
Authorization: Bearer secret-token:NJ6EQYNR4AWDGKCAADDWM41PYKQBBR8K3ZQHJR9YHXT8GDA36KRG
Host: localhost:8083
Connection: keep-alive


HTTP/1.1 204 No Content
Date: Thu, 26 Feb 2026 12:08:43 GMT
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: *


GET /instances/minst1/private/accounts HTTP/1.1
Accept: application/json
Authorization: Bearer secret-token:NJ6EQYNR4AWDGKCAADDWM41PYKQBBR8K3ZQHJR9YHXT8GDA36KRG
Host: localhost:8083
Connection: keep-alive


HTTP/1.1 200 OK
Date: Thu, 26 Feb 2026 12:08:43 GMT
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: *
Cache-Control: no-store
Content-Type: application/json
Content-Length: 261

{
  "accounts": [
    {
      "active": false,
      "payto_uri": "payto://x-taler-bank/localhost/minst1?receiver-name=minst1",
      "h_wire": "RQBZ243D9M70BW3T7Z1QV02HRQ3D5J8DV96XQEB85Z2YWSS4A0CZ8XDH875AG52D68XQR76KDGSCX7YPZ5WJPWRGSF887RWQHRJNMB0"
    }
  ]
}

Basically, the only account is DELETEd, leaving zero available accounts for that instance for any exchange. Hence 204 is the correct answer.

Florian Dold

2026-02-26 22:57

manager   ~0027914

Eh, the problem is actually something else: The test (1) adds (2) removes and then (3) re-adds the bank account.

Thus it correctly expects a non-empty /kyc response after (3).

However, the merchant:
* Returns an *undocumented* 204 response for "POST /.../private/accounts"
* Subsequently seems to *not* re-activate the bank account (still listed as "active: false")

This looks wrong, since it means a merchant can trivially/accidentally break their merchant instance *forever* w.r.t. being able to use that particular bank account.

Christian Grothoff

2026-02-26 23:40

manager   ~0027915

Fixed in 477831b8..40fcdf6f. Test passes now.

Issue History

Date Modified Username Field Change
2025-12-19 02:37 vecirex New Issue
2025-12-19 02:39 vecirex Steps to Reproduce Updated
2025-12-19 02:40 vecirex Assigned To => vecirex
2025-12-19 02:40 vecirex Status new => assigned
2025-12-19 02:40 vecirex Note Added: 0027119
2025-12-19 02:41 vecirex Note Edited: 0027119
2025-12-19 02:44 vecirex Summary test case: try to not use an IBAN anymore, deleting a bank account or the whole instance; can IBAN be reclaimed? => Test case: try to not use an IBAN anymore, deleting a bank account or the whole instance; can IBAN be reclaimed?
2026-01-26 07:34 Christian Grothoff Target Version => post-1.0
2026-02-14 18:59 Florian Dold Summary Test case: try to not use an IBAN anymore, deleting a bank account or the whole instance; can IBAN be reclaimed? => Test case: try to not use an IBAN anymore, deleting a bank account or the whole instance; can IBAN be reclaimed? [20min]
2026-02-15 10:23 vecirex Assigned To vecirex => Christian Grothoff
2026-02-15 10:23 vecirex Note Added: 0027731
2026-02-15 10:24 vecirex Note Edited: 0027731
2026-02-16 23:23 Christian Grothoff Product Version => 1.3
2026-02-16 23:23 Christian Grothoff Target Version post-1.0 => 1.5
2026-02-16 23:34 Christian Grothoff Relationship added parent of 0010810
2026-02-16 23:35 Christian Grothoff Note Added: 0027765
2026-02-16 23:35 Christian Grothoff Tag Attached: vivy
2026-02-16 23:35 Christian Grothoff Priority high => urgent
2026-02-16 23:35 Christian Grothoff Status assigned => confirmed
2026-02-16 23:53 Christian Grothoff Relationship added related to 0010703
2026-02-17 21:32 Christian Grothoff Assigned To Christian Grothoff => Florian Dold
2026-02-17 21:32 Christian Grothoff Status confirmed => assigned
2026-02-17 21:41 Christian Grothoff Tag Detached: vivy
2026-02-22 15:34 Christian Grothoff Relationship added related to 0011069
2026-02-22 15:38 Christian Grothoff Relationship replaced related to 0010810
2026-02-22 15:39 Christian Grothoff Relationship added related to 0010974
2026-02-23 12:24 Christian Grothoff Tag Attached: customer
2026-02-23 20:49 Florian Dold Note Added: 0027871
2026-02-25 18:50 Florian Dold Status assigned => feedback
2026-02-26 13:08 Christian Grothoff Note Added: 0027909
2026-02-26 13:09 Christian Grothoff Note Added: 0027910
2026-02-26 13:37 Christian Grothoff Note Added: 0027911
2026-02-26 22:57 Florian Dold Note Added: 0027914
2026-02-26 22:57 Florian Dold Assigned To Florian Dold => Christian Grothoff
2026-02-26 23:40 Christian Grothoff Note Added: 0027915
2026-02-26 23:40 Christian Grothoff Status feedback => resolved
2026-02-26 23:40 Christian Grothoff Resolution open => fixed
2026-02-26 23:40 Christian Grothoff Fixed in Version => 1.5