FgForrest / evitaDB

evitaDB is a specialized database with an easy-to-use API for e-commerce systems. It is a low-latency NoSQL in-memory engine that handles all the complex tasks that e-commerce systems have to deal with on a daily basis. evitaDB is expected to act as a fast secondary lookup/search index used by front stores.
https://evitadb.io
Other
62 stars 7 forks source link

Cannot close read-write session with uncommited changes in filled catalog in gRPC JSON transcoding mode #648

Open lukashornych opened 3 months ago

lukashornych commented 3 months ago

When using gRPC JSON transcoding mode (not pure gRPC-web), calling close() on session in following edge-case results in

{
  "code": 1,
  "grpc-code": "CANCELLED"
}

and 503 status code.

It happens only for our demo dataset, not in new empty catalog (empty collections may be present). It happens when

  1. read write session is created
    curl -XPOST -H 'content-type: application/json; charset=utf-8; protocol=gRPC' 'http://localhost:5555/io.evitadb.externalApi.grpc.generated.EvitaService/CreateReadWriteSession' -d '{
    "catalogName": "evita",
    "commitBehavior": "WAIT_FOR_INDEX_PROPAGATION",
    "dryRun": false
    }'
  2. some new stuff is written to the transaction
    curl -XPOST -H 'content-type: application/json; charset=utf-8; protocol=gRPC' -H 'sessionid: 8a64c239-c5e2-421b-b193-d8882c9f6f77' 'http://localhost:5555/io.evitadb.externalApi.grpc.generated.EvitaSessionService/DefineEntitySchema' -d '{
    "entityType": "test"
    }'
  3. the session is then closed
    curl -XPOST -H 'content-type: application/json; charset=utf-8; protocol=gRPC' -H 'sessionid: 8a64c239-c5e2-421b-b193-d8882c9f6f77' 'http://localhost:5555/io.evitadb.externalApi.grpc.generated.EvitaSessionService/Close' -d '{
    "commitBehaviour": "WAIT_FOR_CONFLICT_RESOLUTION"
    }'

It can be tested in the gRPC docs tool http://localhost:5555/grpc/doc where the JSON transcoding is used (we used accidentally this mode in evitaLab too, but not anymore. The pure gRPC-web mode works just fine).

Don't know if there is any solution to this, evitaDB server logic itself doesn't throw any error, it closes the session correctly under the hood. But something along the way, maybe in the Armeria server transcoding process gets broken.

cc @Khertys, @novoj