Error handling improvement suggestion from customer-email

[steininger]

Dear fiskaltrust team,

we kindly ask, if it is possible to extend your IPos.v0 interface.
Currently, erroneous requests are rejected where we would expect a fiskaltrust.ifPOS.v0.ReceiptResponse with some error details.
This is very difficult to handle.

If, for instance, we would send a fiskaltrust.ifPOS.v0.ReceiptRequest with an invalid value in ftCashBoxID, we suggest to return an answer like the JSON sample below:

• ftState should indicate a reject, e.g. "0x44450000000000FF"
• ftStateData could return the reason for the rejection, e.g. "ftCashBoxID invalid"
  Another place to return the reason could be a ftSignatureItem with a special ftSignatureType (e.g. "0x44450000000000FF")
• Since the data is not stored on your side, your return values, e.g, ftQueueItemID and ftQueueRow , should be empty or -1.
• To make it more obvious, that this is a rejection, no data from the cbReceiptRequest needs to be returned, e.g. ftCashBoxID.

In JSON the fiskaltrust.ifPOS.v0.ReceiptResponse Would then be like this:
{
"ftCashBoxID": "",
"ftQueueID": "",
"ftQueueItemID": "",
"ftQueueRow": -1,
"cbTerminalID": "",
"cbReceiptReference": "",
"ftCashBoxIdentification": "",
"ftReceiptIdentification": "",
"ftReceiptMoment": "2021-04-30T04:35:57.126946Z",
"ftSignatures": [
{
"ftSignatureFormat": "0x1",
"ftSignatureType": "0x44450000000000FF",
"Caption": "Error",
"Data": " ftCashBoxID invalid "
}
],
"ftState": "0x44450000000000FF",
"ftStateData": "{"Error":" ftCashBoxID invalid"}"
}

[TSchmiedlechner]

Hi,
thanks alot for reaching out, the detailed problem description and your suggestions! You're correct, the Middleware currently doesn't really return error messages that are nicely "machine-readable" in some cases.

We are somewhat limited by the different hosting frameworks we support (e.g. gRPC handles errors differently than REST). Your suggestion sounds interesting, but is hard to implement as of now, as many users of our Middleware are handling the returned exceptions now, so this what be a breaking change.

It might still be interesting for a future major release though, I'm keeping this open therefore. Unfortunately, we will not implement this in a minor release meanwhile - if you need to proceed with your implementation, I'm afraid that you will need to catch the thrown exceptions.

[StefanKert]

So IMO we do have two main things to consider here:

• Internal handling of errors

I think that for internally handling errors we can perform the necessary changes without actually breaking anything and still providing additional insights via Portal. This would have an immediate impact on debugability / tracing errors via portal and the effort is very low. By just wrapping the sign operation in a try catch, setting the response and storing it with some additional error information we already get a huge benefit and don't break anyone. As long as we just rethrow this exception we do not alter behavior and the caller sees the exact same thing. IMO that is something that we should do immediately to improve lots of things

@volllly maybe you can add your two cents since I think that could be a low effort change that has a huge impact for customers and support

• External handling of errors

This external handling, as @TSchmiedlechner mentioned already, is more or less tricky since we don't know how callers are handling the call. I would still though think about adding a Queue (probably even Launcher) parameter to alter that behavior and use the new error handling.

[StefanKert]

Regarding the casing I think that we should follow along with the v2 tagging:

0x4445_0000_0000_00FF

• First part is market (4445)
• Next bucket is vlll where l is used for local flags (TSE not rechable eg.) (0000)
• Next bucket is gggg where g is used for global flags (retry possible / required)
• The last bucket is used for indication of the state (FF / EE => failed) and 00 for to indicate some more specific error code

[volllly]

By just wrapping the sign operation in a try catch, setting the response and storing it with some additional error information we already get a huge benefit and don't break anyone.

So In case the Sign call to the localized SignProcessor fails we:

• create a ReceiptResponse with EE ftState that contains e.g. the exception message
• insert that ReceiptResponse in a ftQueueItem into the ftQueueItems table
• and throw the exception we get so we don't change behaviour

[StefanKert]

By just wrapping the sign operation in a try catch, setting the response and storing it with some additional error information we already get a huge benefit and don't break anyone.

So In case the Sign call to the localized SignProcessor fails we:

• create a ReceiptResponse with EE ftState that contains e.g. the exception message
• insert that ReceiptResponse in a ftQueueItem into the ftQueueItems table
• and throw the exception we get so we don't change behaviour

Exactly, so to have the receipt response with the error message available.

@TSchmiedlechner what you you think?

[TSchmiedlechner]

Sounds like a great idea for sure 😁

[StefanKert]

Not really closed, we should consider this for AT/DE/FR too