Only some Cashboxes work, the others return 500 - Internal Server Error
JulianSchmidtke opened this issue · 4 comments
Describe the bug
We create two Cashboxes in the same way. We create a new Queue for each one and the queues reference the same tse.
When we call the /api/echo endpoint for one, we receive a successful response. The other returns 500 - Internal Server error.
We had this problem with many cashboxes, but cannot see a pattern.
To Reproduce
Create one TSE
Create Two Queues (with http endpoint)
Create two Cashboxes
Sometimes only one works..
Expected behavior
Cashboxes created this way should echo without an error.
It should work like here:
https://docs.fiskaltrust.cloud/de/docs/posdealers/rollout-doc/middleware#konfiguration-der-scu
STDOUT/STDERR
This is the only log i found. I have no idea if it is because of our error or something completely different:
2021/03/04 14:58:45 kubernetes:secret\|bring-your-own-datacenter\|*\|hostname=*: ERROR: WORKER PANICKED: unable to parse requirement: invalid label value: "*": at key: "hostname": a valid label must be an empty string or consist of alphanumeric characters, '-', '_' or '.', and must start and end with an alphanumeric character (e.g. 'MyValue', or 'my_value', or '12345', regex used for validation is '(([A-Za-z0-9][-A-Za-z0-9_.]*)?[A-Za-z0-9])?')
Cashbox Information (please complete the following information):
Working:
1b6318aa-5cf5-44c8-8cce-5825497bc6c3
Not working:
d372f363-9872-48b5-a62c-1a5ec597655b
55a75454-5f2e-4d81-86e1-ae215b38157c
Additional context
If we created the cashbox in a wrong way, please send us the wiki page with a working sample solution.
Without actively changing a configuration the CashBox d372f363-9872-48b5-a62c-1a5ec597655b does work now. A newly created Cashbox 9e5c3b98-1efc-4a95-a53a-c2a71c143e61 does not.
Hi Julian,
thank you for your inquiry.
May i ask you for some additional information:
- active config of this namespace
- is this STDERR from a backendpod?
BR
Hi Julian,
we investigated this issue partially with cashboxid 9e5c3b98-1efc-4a95-a53a-c2a71c143e61.
- The SQL Connectionstring in the queue seems to be not valid. As long as I cannot access your database (hopefully :-)) this is not testable for us.
- I added some info to Operational Reference (https://github.com/fiskaltrust/product-de-bring-your-own-datacenter/blob/master/OperationsReference.md#supported-rollout-scenarios) regarding endpoints of Queues and SCUs. Technically it makes no difference but is checked by the middleware code. This is the reason why "URI Check" errors appear in the Backendpod while sending a request against it.
I hope this helps a bit.
BR Christian
As there are no further questions, i will close this issue...