and which actually might parse ok on a second attempt in v20.07.0 but then the server might get unavailable. Please understand that i wouldn’t look into the details of the regression this is just to let you know that IMHO something fishy is going on here. I even modified my start script to clean the whole ~dgraph directory before running the tests.
Running the tests against a local Ubuntu server also works.
running v20.07.0 against a local MacOS docker image gives a message like the below one 3 x
grpc._channel._InactiveRpcError: <_InactiveRpcError of RPC that terminated with:
status = StatusCode.UNAVAILABLE
details = "Socket closed"
debug_error_string = "{"created":"@1597224818.140421000","description":"Error received from peer ipv6:[::1]:9080","file":"src/core/lib/surface/call.cc","file_line":1055,"grpc_message":"Socket closed","grpc_status":14}"
>
v20.03.0 also fails -but the message appears only twice - so the problem seems to show up later.
Interesting to see another unavailable issue … I’m wondering if this is connected to my issue with the server suddenly becoming unavailable after a few hours running. I restart and things run again - but I’m also seeing a gradual increase in the memory footprint - it’s almost like the server runs out of resources, making me suspect that something’s not being cleared down, so after a while it can’t accept any more connections.
Whatever it is, it’s a relatively new thing because my code’s been stable until the latest updates. Now it fails every 24-hours. See Corrupt database issue if you think these might be related. If not, sorry for crashing the thread
The clien is always running on MacOS host - I am working against different backends on Mac OS docker or Ubuntu docker to get things running. The Mac OS docker environment is the unstable environment. I did not increase the standard 2 GB RAM Setting yet. Unfortunately I currently also have other issues that need to be fixed and clarified.
Note how this is only for one of the three runs python 3.7 and 3.8 run fine. I doubt that the issue is acutally connected to the python version. I’ll try a rerun to proove this. It looks like this behavior is totally unpredicatable so I’d suspect a timing issue.
Looks like acronym is the convict here as can be seen from the log message ( attr:“acronym” value:“BTW”). From the source code too, it looks like it is defined as string. This makes me think if that shcema is used, why does dgraph trying to parse it to int.
But it is working with python3.7 and python3.8 as you said. So maybe it could be a python or dgraph client issue.
It’s totally random. Sometimes the python3.8 code fails and sometimes another one. So far it never happened that all thee were succesful. IMHO there is something really fishy going on here. It does not make any sense to try to parse btw… as int. The error message is proably misleading.