[stamateviorel]

A meter-less/FreeMode charge point (Phoenix Contact CHARX, no internal energy meter) can legitimately omit meterStop or transactionId from StopTransaction. The embedded library's StopTransactionRequest.validate() requires both plus timestamp, so the reply is a CallError instead of a confirmation — the charge point retries, gives up, and the transaction never closes, leaving the connector holding a phantom transaction.

Different layer than the merged "acknowledge StopTransaction for unknown transactions" fix, which runs after validate() passes, for a valid-shaped stop with an unrecognized id — this fixes validate() itself, which runs first and never lets a malformed-shaped stop reach that code.

OCPP 1.6 requires the CSMS to acknowledge StopTransaction regardless of its contents, so the override only requires a timestamp — implemented as a local class that shadows the embedded library one (our sources precede it on the Bundle-ClassPath), since validate() isn't something a handler can intercept.

[splatch]

Looking at the code I think there is one more way, however take this with grain of salt as I just look at the flow on our end, completely missing how library handles that internally.
Wouldn't it be better to implement a handleStopTransactionRequest which will return our own PermissibleStopTransactionRequest with relax validation logic?
We do not need to copy entire class, but as far I understand issue boils down to CoreEventHandlerWrapper.java#L79:

      if (confirmation == null && handlerConfirmation != null && handlerConfirmation.validate()) {
        confirmation = handlerConfirmation;
      }

The handlerConfirmation instance comes from our own handler, thus it should be possible to influence its creation.