taler-docs

Documentation for GNU Taler components, APIs and protocols
Log | Files | Refs | README | LICENSE

055-wallet-problem-report.rst (2818B)

      1 DD 55: Wallet Problem Reports
      2 #############################
      3 
      4 .. note::
      5 
      6    **Status**: Early work in progress / DD number reservation.
      7 
      8 .. warning::
      9 
     10    We concluded that we don't need the problem reports feature right now,
     11    as all cases we care about are already covered by something else.
     12 
     13 Summary
     14 =======
     15 
     16 This design document specifies global error reports generated/managed by wallet-core
     17 and rendered by the wallet UIs.
     18 
     19 Motivation
     20 ==========
     21 
     22 Sometimes the wallet encounters issues that go beyond the scope of single transaction.
     23 
     24 Requirements
     25 ============
     26 
     27 * problem reports must have a clear lifecycle
     28 * problem reports must have some type of identification that allows to
     29   easily find out if a new problem report needs to be created when an
     30   error happens or whether an existing one has been created
     31 
     32 Proposed Solution
     33 =================
     34 
     35 Report identification
     36 ---------------------
     37 
     38 The report identifier serves multiple purposes:
     39 
     40 1. Usage as a reference in wallet-core APIs
     41 2. De-duplication. The report ID should allow easy identification of an already existing report for a particular problem.
     42 
     43 New wallet-core requests
     44 ------------------------
     45 
     46 * ``listProblemReports``
     47 * ``acknowledgeProblemReport``: Mark a problem report as read.
     48 * ``deleteProblemReport``: Delete the problem report.
     49 
     50 New wallet-core notification type
     51 ---------------------------------
     52 
     53 * ``problem-report`` to notify clients about status changes or an error report
     54   (including creation!)
     55 
     56 
     57 Types of reports
     58 ----------------
     59 
     60 (Currently we don't have any good examples where this is actually needed.)
     61 
     62 Examples of what should NOT be a report
     63 ---------------------------------------
     64 
     65 * money lost due to the exchange stopping to offer a denomination
     66 
     67   * => Should be a transactions item
     68 
     69 * money locked behind a (long) pending refresh
     70 
     71   * => Should be a pending transaction
     72 
     73 * money lost due to a permanently failing refresh
     74 
     75   * => pending or final transaction item
     76 
     77 * money lost due to expired denominations (auto-refresh wasn't done fast enough)
     78 
     79   * => transaction item
     80 
     81 * a denomination changed its info (expiration, fees)
     82 
     83   * => exchange entry state
     84 
     85 * Important information about the exchange changed (master pub, accounts, keys)
     86 
     87   => exchange entry state
     88 
     89 
     90 Definition of Done
     91 ==================
     92 
     93 TBD.
     94 
     95 Alternatives
     96 ============
     97 
     98 * Report problems with an API specific to each resource (exchange entry, transaction, ...)
     99 * Have an *alerts* API that returns alerts to the client that the client can show to to the user,
    100   but that a user can't interact with.
    101 
    102 Drawbacks
    103 =========
    104 
    105 TBD.
    106 
    107 Discussion / Q&A
    108 ================
    109 
    110 * When is a report amended vs a new report created?
    111 
    112  * example: Exchange stops offering denomination D1. Later, it stops offering D2.
    113    Are two reports generated or is the first report changed?
    114