Reusing `Cassandra.Data.Linq.Table<T>` for querying returns wrong results

I did some refactoring in code and instead of creating the Table<TEntity object for every operation I thought I could do away with this code duplication.
The result I ended up with was something which worked locally when testing (unit tests, even concurrent and manual tests) but when deploying to production queries sometimes unexpectedly returned no results (even though the data is there and is returned by other queries with different filters).

Since the Table<TEntity> class is not documented as being thread-safe it looks like it’s my own fault that stuff broke. Not sure if it’s actually intended to be thread safe, in this case this would be a bug.
Even if it isn’t a bug, it would be nice if the code could be changed to be either thread-safe or detect if it’s misused and throw an exception stating a likely problem source (like for example List<T> does when iterating while modifying).

I think this is best explained by showing how I changed the code and documenting it’s behavior:

Entity + Mapping

Original Way to Access the Data

After Refactoring

The significant change being that Table<ExportFolderAssignmentCassandraEntity> is now created in the ctor of the class and shared along all methods.

Symptoms

• .GetAllForServerUser(serverUserId) would correctly return all elements

• however, retrieving a single element via .Get(serverUserId, Id) would sometimes return nothing instead of the expected element.

  • no elements are being added or removed in the meantime

  • it doesn’t affect all combinations of serverUserId, Id - that is, some queries returned the expected result while others returned nothing

  • inside the same process the results seemed to be consistent; that is, a combination of serverUserId, id which returns no result does not return a result a half an hour later, too.