-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[QLDB] Unable to create QLDB Stream in .NET #10513
Comments
We have the same problem. We have tried multiple formats, and either get the same error during |
@t1agob thanks for reporting, can you share the regular string you've used? I'm not familiar with QLDB yet, but I'm going to start by trying to deploy the sample app. does an @peron - was your issue also specific to |
@shivlaks no, the values in the example do not work. On the code I pasted when opening the issue I am getting the date in the specific format mentioned on the example but I have also tried to use a string like the one in the example. Got the same error. |
@t1agob got it, thanks for confirming, I'll start with that example in TypeScript first and then build up. I'll provide an update once I take a look. |
@shivlaks In Typescript it works without any issue. I moved all my CDK code from .Net to Typescript due to this issue. |
@t1agob all right that saves me some debug time. so when using the same string value directly, does the failure occur during synthesis for |
@shivlaks both synthesis and deploy. The stacktrace above is from a |
The value appears to be round-trip-ing though a jsii Callback. I would not be surprised if the .NET JSON serializer actually deserializes the ISO-8601 string into a Date, and it's all broken from there on. I think this qualifies as a bug in the .NET runtime library for jsii. |
When a ISO-8601-encoded date is passed from JavaScript to the .NET app, the JSON deserializer would interpret that as a `DateTime` instead of passing the string un-touched. This is a problem, since the jsii kernel protocol has a dedicated wrapper key for DateTime values (`$jsii$date`). This PR adds a compliance test around this particular scenario, and disabled `DateTime` handling from the standard deserializer (the wrapped values are still processed correctly). This bug was identified in aws/aws-cdk#10513
When a ISO-8601-encoded date is passed from JavaScript to the .NET app, the JSON deserializer would interpret that as a `DateTime` instead of passing the string un-touched. This is a problem, since the jsii kernel protocol has a dedicated wrapper key for DateTime values (`$jsii$date`). This PR adds a compliance test around this particular scenario, and disabled `DateTime` handling from the standard deserializer (the wrapped values are still processed correctly). > This PR also changes the way the .NET test package generates the > tested libraries (`jsii-calc` & dependencies) so that instead of > generating NuGet packages, it only generates C# projects. This makes > the experience of debugging the tests **much** nicer, and reduces the > likelihood of cached build artifacts getting in the way. This bug was identified in aws/aws-cdk#10513
My assumption was confirmed and I am looking to release the fix today 🎉 |
When a ISO-8601-encoded date is passed from JavaScript to the .NET app, the JSON deserializer would interpret that as a `DateTime` instead of passing the string un-touched. This is a problem, since the jsii kernel protocol has a dedicated wrapper key for DateTime values (`$jsii$date`). This PR adds a compliance test around this particular scenario, and disabled `DateTime` handling from the standard deserializer (the wrapped values are still processed correctly). > This PR also changes the way the .NET test package generates the > tested libraries (`jsii-calc` & dependencies) so that instead of > generating NuGet packages, it only generates C# projects. This makes > the experience of debugging the tests **much** nicer, and reduces the > likelihood of cached build artifacts getting in the way. Fixes aws/aws-cdk#10513
I see you got around this quickly! So my answer might not be that important anymore, but yes, we also use .NET. Since the problem occurred during synthesis, we ended up doing this in the stack file:
and ended
and that worked for us. |
I am getting an error creating a QLDB Stream from CDK using .NET. The CfnStream class requires a InclusiveStartTime property of type string, which is a UTC date in ISO8601 format. ex: 2019-11-05T13:15:30Z.
I am using the following code to get to this format but I have also tried specifying a regular string in the correct format. It didn't work either.
This is the exception I am getting.
I tried replicating the same CDK stack using TypeScript and it worked.
Reproduction Steps
What did you expect to happen?
I expected the cdk deploy command to succeed.
What actually happened?
Environment
Other
I see that there are other issues that seem related to this one 7392 and 5317
This is 🐛 Bug Report
The text was updated successfully, but these errors were encountered: