0011981: Dead code in merchant-terminal: deleteCurrentOrder and newPaymentId have no callers; refundExternalPayment is reachable only from its tests

ID	Project	Category	View Status	Date Submitted	Last Update
0011981	Taler	merchant-pos-terminal (Android App)	public	2026-11-09 16:36	2026-11-09 16:36

Reporter	bot-cg [agent]	Assigned To		Resolution deadline
Implementer		Reviewer
Release signed by		Deployed by
Verifier		Communicator	CM_7
Data protection authority notification required	No
CSIRT notification required	No
Estimated effort (hours)		Actual effort (hours)	0
Fast-track	No
Work package	none
Priority	normal	Severity	minor	Reproducibility	have not tried
Status	new	Resolution	open

Summary	0011981: Dead code in merchant-terminal: deleteCurrentOrder and newPaymentId have no callers; refundExternalPayment is reachable only from its tests
Description	Three functions in merchant-terminal are implemented but cannot be reached from the running app. Two have no callers at all, in any source set; the third is called only by its own unit tests. None of this is visible to a cashier -- it is a code-health report -- but the second one looks like a feature that lost its button, which may not be intentional. Checked across main/, debug/, sim/, androidTestSim/ and test/ of merchant-terminal, plus merchant-lib and taler-kotlin-android, for both call syntax (`name(`) and method references (`::name`). 1. OrderManager.deleteCurrentOrder() -- no callers anywhere merchant-terminal/src/main/java/net/taler/merchantpos/order/OrderManager.kt:309 A complete implementation, about 25 lines: it removes the current order, picks the neighbouring order to show instead, and recreates an empty one if the order removed was the last. Nothing invokes it. The terminal does let a cashier keep several orders at once -- the order screen shows "Order #0" with Prev and Next buttons, wired in MainActivity.kt:714-715 to OrderManager.previousOrder()/nextOrder() -- but there is no delete-order control in the UI at all; `grep` finds no string and no call site for one. So a cashier can create orders and move between them but cannot remove one. It arrived in 5bf1f8c6 ("[pos] tiny update (migrate to compose)"), which suggests the control was lost in that migration rather than never written. If the feature is wanted, the manager side is already there; if it is not, the function can go. 2. CheckoutManager.newPaymentId() -- no callers anywhere merchant-terminal/src/main/java/net/taler/merchantpos/checkout/CheckoutManager.kt:220 fun newPaymentId(): String = newId() One line, from 24f7b249 ("[pos] add support for mixed payments and UI changes"). Payment ids are minted by `newId()` directly everywhere else. 3. CheckoutManager.refundExternalPayment() -- only its tests call it merchant-terminal/src/main/java/net/taler/merchantpos/checkout/CheckoutManager.kt:441 About 34 lines, exercised by six cases in CheckoutManagerTest, and not reached from any UI: RefundFragment records a refund of an external payment through RefundManager.recordExternalRefund() instead. So the checkout-side path is maintained and tested but cannot run in the app. This one may well be deliberate -- a path kept for a UI that has not landed yet -- which is why it is reported as an observation rather than as a defect. It would be useful to know which, because from the outside the two paths look like duplicates of each other. WHY IT IS WORTH A TICKET Besides the usual cost of code that cannot be run, this skews test-coverage measurement. The pos-simulator harness ranks what to test next by uncovered lines, and these ~60 lines sit near the top of the list for merchant-terminal while being impossible to reach from any test that drives the app. I am excluding them in the harness so that they stop being chased; a note here seemed better than silently special-casing them in a tool nobody else reads. No patch attached: whether each of these should be deleted or wired up is a decision for whoever owns the feature, not something to guess at. Happy to prepare one either way -- say which, and for the first one whether the delete control should come back.
Steps To Reproduce	Static, no device needed, from a checkout of master (58b2417d): cd merchant-terminal grep -rn "deleteCurrentOrder" --include=.kt ../merchant-terminal ../merchant-lib ../taler-kotlin-android grep -rn "newPaymentId" --include=.kt ../merchant-terminal ../merchant-lib ../taler-kotlin-android grep -rn "refundExternalPayment" --include=*.kt ../merchant-terminal Observed: the first two match only their own declaration. The third matches its declaration plus six call sites, all in src/test/java/net/taler/merchantpos/checkout/CheckoutManagerTest.kt. Expected: either a call site in the app, or the function removed.
Additional Information	taler-android master at 58b2417d (2026-11-09). Found while ranking uncovered lines for the pos-simulator harness. The order-delete case is the one worth a decision: OrderManager keeps several orders and the UI can move between them with Prev/Next, so the absence of any delete control looks like an omission rather than a choice.
Tags	No tags attached.

View Issue Details

Required notifications

Activities

Issue History