mirror of
https://github.com/logos-co/eth-lez-atomic-swaps.git
synced 2026-08-27 18:01:10 +00:00
Danish Arora
d4ffe82235
* fix(swap-ui): show the insufficient-funds error once; measure the protocol stamp Two items on a public tester's first five minutes, one fixed and one established as out of reach of the change it was scoped for. FIXED — the insufficient-funds error was displayed twice. PR #157 added the funds guard and the plain-language translation for both surfaces but explicitly left the duplication ("Not done here: the same failure still appears on both the sticky error strip and the receipt card"). It still does: handleTakerFinished() writes takerResultJson, which the "Your swap" receipt card renders, and then setResultStatus() writes errorMessage, which the shell's sticky strip latches — one backend event, the same sentence ~200px apart, read as two separate problems. The receipt card keeps it. It is attached to the swap that failed, HistoryView re-renders the identical card for the archived copy, and an error receipt has nothing else in it (every evidence row hides behind !isError), so removing the sentence would leave a bare "ERROR" box. The GLOBAL strip stands down while the tab owning that receipt is on screen and returns as soon as the user navigates away — which is exactly when a global notice earns its place, since the copy sends them to the Setup tab to add ETH. #157's guard, copy, and raw-error journalling are untouched, as is every failure that produces no receipt (start failures, config, balances, refunds): those still take the strip, which remains their only surface. NOT FIXED — the protocol stamp needs a migration, not a pin bump. Confirmed from the artifacts, not from reasoning: swap_plugin.dylib carries no logos_protocol_version in its CBOR plugin metadata and takes liblogos's AllowLegacy path; swap_ui_plugin.dylib carries 0.2.0. The stamp lives ONLY in the plugin binary — not in the .lgx manifest, and not in the bundled metadata.json, both of which were checked and have it in neither module. The cause is the logos-module-builder pin, as expected: b15a3724 has no stampProtocolVersion at all. But no repin reaches a stamped, 0.2.0, buildable swap. Measured rev by rev, each attempted and built: * 33bcd1c (#113), the first rev that stamps, stamps 0.1.0 — a skew against swap_ui — and its Qt split reshapes swap_qt_glue.h so swap-module's own preConfigure splice, which injects the delivery adapter, matches nothing. Build fails after stamping. * 24cec35 (#119) onward move Qt-glue generation to logos-qt-generator and drop logos-cpp-generator --backend qt, which swap-module's preConfigure calls directly. Build fails there too, still at 0.1.0. * logos-protocol reaches 0.2.0 only around 6ef42ea, well past that removal, and by then the generated glue is the cdylib set, which does not match CMakeLists.txt's SOURCES either. * From 01bb03f (#175) delivery_module v0.1.1 cannot be consumed at all ("cannot be consumed by an lp (Qt-free) module") without a v0.2.x bump. So closing it means migrating swap-module onto the cdylib glue and re-homing the delivery-adapter injection — a real change to the build graph, deliberately not attempted here, this being the last change before a public trial. What this commit does leave behind is the measurement, so the next attempt starts from evidence: .github/scripts/check-protocol-stamp.py reads the stamp out of a built .lgx or an installed plugin, fails on an unstamped plugin and on a protocol skew between the two modules, and carries the rev-by-rev findings in its header. It replaces the inline check in build-modules.yml, which was wrong: its regex matched the field NAME anywhere in the binary, linked liblogos code included, so it could report a stamp on a module that has none. The step stays report-only until the migration lands; dropping that one flag turns it into the gate. * no-mistakes(review): execute indexOfTab in tests; neutral stamp-check headline * no-mistakes(review): drop stray .pyc; ignore Python bytecode