hernani/taler-monitoring
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

docs: §3b mint 5110/P0001 with dated landing withdraw examples

Browse source 
Record recurring bank SQL 5110/P0001 as server-side (not mon/wallet),
max-search fail band ~824k GOA, and same-day landing recent_withdraws
that still show Giga/Mega explorer mints succeeded earlier.
This commit is contained in:
Hernâni Marques 2026-07-19 14:49:08 +02:00
parent fd5ac80566
commit 5c312833e1
No known key found for this signature in database
1 changed files with 57 additions and 7 deletions
Download patch file Download diff file Expand all files Collapse all files

64
CLI-AUTOMATION-NOTES.md
View file

@ -67,15 +67,65 @@ Legend:
| **Workaround** | Use `LADDER_STEPS≥5` (or higher) so random mids exist; treat zero / absolute-max / max-1-5110 as probes (soft `CEILING_REJECT` in mon ≥1.20.2). |
| **Wanted** | Ladder plan docs: pin vs mid semantics; CLI structured error for amount-too-large / zero. |
### 3b. Higher withdraw amounts often fail at mint
### 3b. Mint fails with bank SQL `5110` / `P0001` (server-side; recurring)
| | |
|--|--|
| **Seen** | Classic GOA ladder high/random mids and ceiling pins — e.g. `GOA:747827072844319` → `FAIL_MINT` / `STOPPED … mint HTTP 500 { code :5110, … P0001 }`; same class of error on max / max-1. |
| **Area** | **bank** / **ops** |
| **Problem** | **Larger amounts** frequently hit bank/libeufin limits (HTTP 500, Taler **5110**, SQL **P0001**). Not specific to pin:max only — mid-high ladder steps fail the same way. Do not treat as wallet/`reserve_pub` when mint never succeeded. |
| **Workaround** | Expect failures above some live ceiling; use max-search / soft ceiling handling; keep mid-range rungs for real withdraw/confirm tests. |
| **Wanted** | Clear amount-too-large from bank (not opaque SQL 500); mon reports ceiling separately from hard fails. |
| **Seen** | **Several times** on GOA (`bank.hacktivism.ch`), classic ladder high/random mids + ceiling pins **and** max-search bisect — not a one-off. Same class of error across 2026-07 runs (magikoopa / mon ladder). |
| **Area** | **bank** (libeufin / taler-corebank + **Postgres**) / **ops** — **not** mon SQL, **not** wallet-cli at mint time |
| **Call site** | mon `POST ${BANK}/accounts/explorer/withdrawals` with `{"amount":"GOA:…"}` only. Wallet/exchange not involved until mint returns 200 + URI. |
| **Response** | HTTP **500**, body e.g. `{ code: 5110, hint: "Unexpected sql error with state P0001" }` |
| **Codes** | **`5110` = `BANK_UNMANAGED_EXCEPTION`** (“no known exception types captured the exception”). **`P0001`** = PostgreSQL SQLSTATE for application `RAISE EXCEPTION` (function/trigger), not a mon bug and not max_wire config alone. |
| **Config check** | Public `/config` still allows huge wires (`max_wire_transfer_amount` ≈ `GOA:4503599627370496.99999999`, `default_debit_threshold` same order). Failing mints are often **far below** that (e.g. ~Kilo-GOA). |
| **API mismatch** | Corebank docs: insufficient funds should be HTTP **409**. Getting **500/5110** means the bank is **leaking** an unmapped SQL error instead of a clean client error. |
| **Problem** | Live mint “ceiling” is **opaque and unstable**. Do **not** treat 5110 as wallet/`reserve_pub` failure when mint never succeeded. Do **not** assume “only absolute pin:max fails” — mid and max-search probes hit the same error. |
| **Workaround (mon ≥1.21)** | Soft `CEILING_REJECT` on 5110/P0001 (classic mids + max pins); **max-ladder** treats mint reject as too-high upper bound and bisects. Keep mid-range rungs for real withdraw/confirm tests. |
| **Wanted (bank)** | Map the SQL condition to a structured error (insufficient funds / amount too large / debit limit) — **not** `BANK_UNMANAGED_EXCEPTION`. Log full `RAISE` text server-side. |
#### What max-search saw (example run, 2026-07-19)
Ladder max-search log (magikoopa):
| Time (local mon log) | Probe | Result |
|----------------------|-------|--------|
| (bisect) | lo ≈ **GOA:822256** (822.256 Kilo-GOA) | still treatable as success path / lower bound |
| probe ~24 | **GOA:824385** (824.385 Kilo-GOA) | mint **HTTP 500 / 5110 / P0001** → soft too-high |
| after | hi := **GOA:824385** | continues bisect |
So the **live single-mint fail band** was ~**822–825 Kilo-GOA** in that run — **not** “only Tera/Peta pins”.
#### Landing page shows **much higher** amounts actually gotten (same day)
Public bank intro stats: `https://bank.hacktivism.ch/intro/stats.json` (and the HTML landing that consumes them). Snapshot **2026-07-19 ~14:47 CEST** (`generated_at_human`).
**Explorer balance still enormous** (so this is not “pool empty” in the UI sense):
| Field | Value (snapshot) |
|-------|------------------|
| `balance_explorer` | **4.5036 Peta-GOA** (`GOA:4503599627250215.32499924`) |
| cumulative `withdraws.total_amount` | **4.5036 Peta-GOA** (292 ops) |
| `withdraws.last_24h` | **3.2366 Peta-GOA** (45 ops) |
**Dated single withdraws that *did* mint** (from `recent_withdraws`, account=`explorer`) — all **before** or around the ~824k fail band above:
| When (CEST) | Amount (alt) | Raw |
|-------------|--------------|-----|
| **2026-07-19 14:19** | **1.9761 Giga-GOA** | `GOA:1976113563` |
| **2026-07-19 14:19** | **1.4495 Giga-GOA** | `GOA:1449489732` |
| **2026-07-19 14:26** | **201.636 Mega-GOA** | `GOA:201635991` |
| **2026-07-19 14:26** | **144.53 Mega-GOA** | `GOA:144530029` |
| **2026-07-19 14:29** | **3.4099 Mega-GOA** | `GOA:3409891` |
| **2026-07-19 14:29** | **1.8009 Mega-GOA** | `GOA:1800875` |
| **2026-07-19 14:42** | 822.256 Kilo-GOA | `GOA:822256` (matches max-search **lo**) |
| **2026-07-19 14:42** | 424.114 Kilo-GOA | `GOA:424114` |
Same calendar day, **~1.5–2 hours earlier**, explorer successfully recorded **Giga-GOA** and **Mega-GOA** withdraws — orders of magnitude **above** the ~824k amount that later returned **5110/P0001**.
**Takeaway:** landing/stats prove higher single withdraws were **possible and recorded**; the 5110 failure is **not** explained by “config max_wire forbids Kilo-GOA” or by the public explorer balance display. Ops should compare **landing `recent_withdraws` + `balance_explorer`** with mon mint 5110 times when filing bank bugs.
**Earlier mon observations (same error class, larger pins):** classic ladder e.g. `GOA:747827072844319` → mint 500/5110/P0001; absolute max / max-1 ceiling probes — see also classic soft `CEILING_REJECT` and max-ladder hi bound.
**Exchange intro (context, not the mint path):** `https://exchange.hacktivism.ch/intro/stats.json` — e.g. snapshot same day: `wire_in_amount` ~Peta-GOA scale, `withdraw_amount` ~`GOA:1.79e6` coin-side; bank landing is the right place for **explorer mint** history.
---
@ -287,7 +337,7 @@ If only a few changes land, these unlock the most automation:
| ladder explorer | `read_secret` / EXP_PW_FILE |
| stage maxima | bank `max_wire` + keys min denom |
| force-select | multi-rpub try; soft-skip confirm; empty scrape → WARN not balance fail |
| higher amounts | mint 5110/P0001 common above live ceiling (§3b); classic soft `CEILING_REJECT`; max-ladder bounds hi; report uses alt_unit_names (Tera-GOA …) |
| higher amounts | mint **5110/P0001** recurring server-side (§3b); landing shows much larger **dated** explorer withdraws (Giga/Mega same day); soft `CEILING_REJECT` + max-ladder hi; alt units in report |
| pay vs balance | never order more than wallet **available** (soft `SKIP_BALANCE`); pendingIncoming does not count as spendable |
| pay wait UX | after withdraw, board lists OK/OK_BANK in **start order** with live wallet `pendingIncoming`/`done` + timer (`LADDER_PAY_WAIT_AVAILABLE_S`, default 90s); same wallet DB as withdraw |
| wallet-db path | Prefer `*.sqlite3` (never `*.json` as db path) |