I am using the JsonServiceClient in a Typescript application leveraging dtos generated through the “types/typescript” NativeTypes plugin.
The “errors” collection on the deserialized response object is consistently empty though :
I can see that there is definitely an errors collection being returned from the server :
the calling code currently looks like this (client is a JsonServiceClient):
the Request dto looks like this :
and the Response dto looks like this :
both the ResponseStatus and ResponseError objects exist in the generated dtos file (and look correct) :
and there are no warnings/errors generated by the JsonServiceClient during the post/response-handling/deserialization process (other than the expected 400 error which contains the validation response) :
the result is the same.
any assistance would be greatly appreciated.
mythz
February 10, 2017, 4:28am
2
It was a case-sensitive issue, that should be fixed from this commit which is available from servicestack-client v0.0.18 that’s now available on npm.
Thank you (as always) for the speedy, qualified response, Demis.
#total_rockstars
1 Like
Hi Demis,
I think you introduced a different error in the changes from 0.0.17 to 0.0.18. Since upgrading we receive errors on most of our requests serializing the message TO the server. Here is an example (using the same call/dtos etc from the original issue) :
If I check the request on the network it appears as though the request object is not being serialized and sent through to the server.
I can see in the Chrome debugger that the request is definitely being passed through to the post method with a validly populated request object :
if I revert the servicestack-client package back to version 0.0.17 (with no other code changes) then the request is serialized as expected :
(but the errors collection reverts back to being unpopulated - obviously)
mythz
February 10, 2017, 4:03pm
5
Unfortunately I can’t repro this, I’ve added tests POST request DTO for node and in the browser but their both working as expected and posting serialized Request DTO in the body, e.g:
POST http://localhost:56500/json/reply/EchoTypes HTTP/1.1
Host: localhost:56500
Connection: keep-alive
Content-Length: 16
Origin: http://localhost:56500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36
content-type: application/json
Accept: */*
Referer: http://localhost:56500/test-typescript
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.8
Cookie: m=34e2:|1d98:t|6cfc:t|77cb:t; ss-opt=perm; ss-pid=9jD5qIxohEoXEIBweszD; ss-id=89OFbHsg0kMhf0YfaQDw; __utma=111872281.1686335051.1467224462.1484506192.1485373522.43; __utmc=111872281; __utmz=111872281.1467224462.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); _ga=GA1.1.1686335051.1467224462
{"string":"foo"}
One thing that’s weird in your example is that you’re specifying the generic type on the call-site, e.g:
client.post<dtos.TokenDto>(request).then(response => ...);
You shouldn’t need to do this when your Service implements IReturn<T>. Can you change it to:
client.post(request).then(response => ...);
And let me know if it makes a difference? Also can you post the generated DTO for AddRecordType.
ok - that worked…but I cannot understand why!!!
for the sake of completeness - here is the generated DTO (for both the message and the nested object) :
mythz
February 10, 2017, 4:56pm
7
What does your IReturn<T> Interface look like? And what ServiceStack Server version are you using?
sorry to mess you around, Demis - this is still an issue (I made an erroneous observation of the results above)
server version is 4.5.6 (latest)
the only salient customisation I’m doing server-side is to add the ResponseStatus property to the typescript dtos :
here is some more debugging info for a different POST :
here you can see the correctly populated Request DTO :
if I debug INTO the servicestack-client then I can see that the request is accurately “stringified” :
and that it is in the body of the request when “fetch” is called :
but if I look at the request in Fiddler, I cannot see the request body :
do you think its possible that the issue lies in one of the servicestack-client dependencies (the es6 shim or the isomorphic fetch)?
mythz
February 11, 2017, 9:48pm
10
weird, I started a new project and imported it from scratch and was able to repro this, it seems the issue was due to not explicitly specifying the url , e.g:
changing:
return fetch(req)
to
return fetch(req.url, req)
resolved the issue and made POST work again for some reason. Anyway updating to the new 0.0.19 of servicestack-client should fix it.
fantastic!
thanks so much for the assistance, Demis!
1 Like
