Specified cast is invalid with LINQ provider

Description

I am running into a very hard to reproduce issue related to the LINQ provider. The class and table looks like the following:

[Table( "user" )]
public class User
{
[PartitionKey]
[Column( "user_id" )]
public string UserId { get; set; }

[Column( "certificate" )]
public string Certificate { get; set; }

[Column( "container" )]
public string Container { get; set; }

[Column( "password" )]
public string Password { get; set; }

[Column( "salt" )]
public string Salt { get; set; }

[Column( "update_timestamp" )]
public DateTimeOffset UpdateTimestamp { get; set; }

[Column( "user_attributes" )]
public Dictionary<string, string> UserAttributes { get; set; }
}

The query:

User user = Users.Where( x => x.UserId == userId.ToLower() ).Execute().FirstOrDefault();

The exception being thrown randomly is:

"ClassName": "System.InvalidCastException"
"Message": "Specified cast is not valid.",
"StackTraceString": " at Cassandra.Row.GetValue[T](Int32 index)\r\n at lambda_method(Closure , Row )\r\n at System.Linq.Enumerable.WhereSelectEnumerableIterator`2.MoveNext()\r\n at System.Linq.Enumerable.FirstOrDefault[TSource](IEnumerable`1 source)...

The problem it seems is that sometimes the column order doesn't match the row data and the cast fails - in this case it's trying to convert a DateTime to String. The table in Cassandra matches the definition above and the only wierd thing is that one of the columns (certificate) was added later after the table was created.

Like I said, this is very hard to reproduce and I have tons of code very similar to this that has no issues.

Environment

None

Activity

Show:
Jorge Bay Gondra
April 24, 2015, 6:17 PM

Are you using the C# driver v2.5.0 or the latest (v2.5.2)?
If you are using v2.5.0, could you update to the latest?

About the exception, could you post the complete stack trace?
Are you altering the table over again (like in a test environment) or it was altered in one point in time?

If the problem is the column order, as a workaround, specifying the columns in the select will avoid this issue:

But I'm really interested in find a way to reproduce and fix it.

Robert Rudduck
April 24, 2015, 11:01 PM
Edited

1) I am using the 2.5.0 driver at the moment. I'll update and give it a shot and see if I can reproduce it.

2) I'll have to scrub it slightly, but I'll get you the rest of the stack as soon as I can. I will say everything further down the stack from there is just our web service code and .net libs.

3) The table was altered once a few weeks ago. I thought it might be a schema disagreement but all nodes report the same schema version. Also the application was restarted when the table was modified - so there wasn't a situation where the table change underneath the running application.

4) Specifying a select projection is exactly how I have fixed it in the few cases I have seen this. I have literally hundreds of queries throught the apps using this provider and it's only been in two cases that I have seen this behavior. Both cases where resolved with an explicit projection.

Jorge Bay Gondra
August 11, 2015, 7:45 PM

Do you have further info about this issue, on how to reproduce it?

Alex Popescu
September 11, 2015, 4:08 AM

Please feel free to reopen if this still occurs.

Cannot Reproduce

Assignee

Unassigned

Reporter

Robert Rudduck

Labels

None

Reproduced in

None

PM Priority

None

Fix versions

None

External issue ID

None

Doc Impact

None

Reviewer

None

Pull Request

None

Epic Link

None

Sprint

None

Pull Requests

None

Size

None

Components

Affects versions

Priority

Minor