[DISCUSS] TELLER/CASHIER | 5 read endpoints return unmarked null stubs, likely since original 2013 implementation

[Ashhar Ahmad Khan]

Hi everyone,

While going through the organisation/teller module I found that
TellerManagementReadPlatformServiceImpl has five methods that are
unimplemented IDE stubs:

- getCashierData(...)
- findTellerTransaction(...)
- fetchTellerTransactionsByTellerId(...)
- getJournals(...)
- fetchTellerJournals(...)

Each body is just:

    // TODO Auto-generated method stub
    return null;

This class is a live @Service bean, injected directly into
CashierApiResource, TellerApiResource, and TellerJournalApiResource.
None of the three resources null-check the return value, so these
five methods back the following endpoints:

    GET /cashiers                        (CashierApiResource)
    GET /tellers/{tellerId}/transactions (TellerApiResource)
    GET /tellers/{tellerId}/transactions/{transactionId} (TellerApiResource)
    GET /tellers/{tellerId}/journals     (TellerApiResource)
    GET /cashiersjournal                 (TellerJournalApiResource)

No ExceptionMapper or Provider in the codebase intercepts a plain
null return (I checked all @Provider classes under
infrastructure/core/exceptionmapper, they only fire on thrown
exceptions).

I verified all five endpoints directly against a local develop-branch
build (Docker), rather than inferring behavior from just one. I
created a minimal office/teller (officeId 1, tellerId 1) so the
teller-scoped endpoints had something real to resolve against:

    GET /cashiers
    GET /cashiersjournal?officeId=1
    GET /tellers/1/transactions
    GET /tellers/1/transactions/1
    GET /tellers/1/journals

All five return HTTP 204 with an empty body, and none of them are
gated by a prior validation or existence check. That last point is
worth calling out on its own: /tellers/1/transactions/1 was queried
against a transactionId that does not exist (no transactions had
been created), and it still returned 204 rather than 404. So the
resource methods call straight into the stub in every case, with
nothing in front of them.

A caller currently gets 204 No Content and no error on all five,
which reads as "no data exists" rather than "this was never
implemented." That seems like the more concerning failure mode of
the two possible ways this could have failed.

Tracing history:

    git log --follow --
.../teller/service/TellerManagementReadPlatformServiceImpl.java

traces this class back to 5afed4776 "Cash Management initial commit"
and 8d3f7af16 "[MIFOSX-2784] Including all transactions in Teller
Cashier transaction list", original MIFOSX-era code. The file has
been actively maintained since (e.g. FINERACT-2079, April 2024,
fixed a real query bug in retrieveCashierTransactionsWithSummary in
this same class and added CashierSummaryAndTransactionsTest), but
that work touched different methods and never reached these five.

    git log --all -S "public Collection<CashierData> getCashierData"
--oneline
    git log --all -S "public TellerTransactionData findTellerTransaction"
--oneline

Both return the same lineage across all branches: the signature
appears at the original Cash Management initial commit (5afed4776),
is touched only by a later checkstyle pass (4585978a4) and, for
getCashierData only, a DTO/type cleanup pass (8c2b7bd82,
FINERACT-2169). No commit in either history introduces a real method
body. The string never coexists with an implementation anywhere in
the repo's full history.

No test in the repository exercises any of the five methods:

    grep -rln
"getCashierData\|findTellerTransaction(\|fetchTellerTransactionsByTellerId\|\.getJournals(\|fetchTellerJournals"
--include="*Test.java" .
    # zero results

None of the three resource classes mark these operations
@Deprecated, and the Swagger operationIds (retrieveAllCashiers,
retrieveAllTransactionsForTeller, retrieveOneTransactionForTeller,
retrieveAllJournalsForTeller, retrieveAllCashierJournals) are
documented as current, supported operations. This doesn't look like
intentionally deprecated surface area.

Given these are read endpoints with unclear downstream consumers,
unlike the CLIENTCHARGE inactivate case, removal doesn't seem like
the right first move here. I'd like the community's input on
direction before doing anything:

- (a) implement the five methods properly,
- (b) leave stubs but throw an explicit "functionality not yet supported"
exception so failures are loud instead of silent, or
- (c) something else community members are aware of that I'm missing, e.g.
a reason these were never prioritized, or a newer replacement path I
haven't found.

I don't have a strong preference between (a) and (b) yet and would
like to hear from the community before picking this up.

Thanks,
Ashhar