2

When I query an AutoQuery service (regular GET request), I get a warning in the log, even if the request works fine. The warning looks like this, for URL: https://localhost:5001/employees?BirthDate%3E=1950-01-01

info: Microsoft.AspNetCore.Hosting.Diagnostics[1]
      Request starting HTTP/2 GET https://localhost:5001/employees?BirthDate%3E=1950-01-01 - -
warn: ServiceStack.Serialization.StringMapTypeDeserializer[0]
      Property 'birthdate>' does not exist on type 'autoquery.ServiceModel.AutoQueries+QueryEmployee'
info: Microsoft.AspNetCore.Hosting.Diagnostics[2]
      Request finished HTTP/2 GET https://localhost:5001/employees?BirthDate%3E=1950-01-01 - - - 200 - text/html 291.5297ms

I've created an example, using the Northwind database, which I got with x mix northwind.sqlite and DTO from the official sample here: https://github.com/ServiceStackApps/Northwind/blob/master/src/Northwind/Northwind.ServiceModel/Types/Employee.cs.

This "false warnings" are a bit troublesome, as there is nothing wrong, and it fills up my logs with warnings that I need to ignore. Especially since I've setup alarms for WARN+ERR in the log.

I working sample here: https://github.com/specimen151/autoquerywarning

specimen
  • 1,735
  • 14
  • 23

1 Answers1

2

This is expected when using AutoQuery's Implicit Contentions where a warning is logged because a request is sent to an API without a matching Request DTO property.

You can either add BirthDate as a typed property of the AutoQuery DTO, or you can ignore all "BirthDate" properties with:

SetConfig(new HostConfig {
    IgnoreWarningsOnPropertyNames = { "BirthDate" }
});

Or you can disable all missing property warnings with:

SetConfig(new HostConfig {
    IgnoreWarningsOnAllProperties = true
});

In the latest v5.12.1 that's now available on MyGet ServiceStack will no longer warn about missing properties on AutoQuery DTOs by default, it can be re-enabled with:

SetConfig(new HostConfig {
    IgnoreWarningsOnAutoQueryApis = false
});
mythz
  • 141,670
  • 29
  • 246
  • 390
  • Hmm. Don't want to ignore all property warnings, because some of them might be real problems, perhaps related to custom DTOs. Generally ignoring property names (such as BirthDate) on every DTO has the same problem. I could explicitly add all properties of the underlying DTO to the AutoQuery object (would inheritance work?), it's just a bit of a hassle, doesn't give to good "AutoQuery feeling" you know. Preferred solution if warnings were not given for these properties that _do_ exist (although dynamically) and which are _not_ a problem. – specimen Aug 25 '21 at 09:58
  • @specimen I'd recommend using implicit conventions during development but adding typed properties for all property queries you're using in production. – mythz Aug 25 '21 at 10:00
  • I tested adding the property: `public class QueryEmployee : QueryDb { public DateTime? BirthDate { get; set; } }` but I still get the warning: `Property 'birthdate>' does not exist on type 'autoquery.ServiceModel.AutoQueries+QueryEmployee'` – specimen Aug 25 '21 at 10:06
  • @specimen yeah because the property name doesn't match, you could use `BirthDateGreaterThan`. I'll add an option for disabling warnings on AutoQuery DTOs. – mythz Aug 25 '21 at 10:14
  • I can confirm that adding `BirthDateGreaterThan` to the AutoQuery DTO does work (the filter) and does _not_ give a warning. Really appreciate the warning-disable on AutoQuery DTOs. That's much better for me (saves a lot of typing, and I can keep prod/dev more similar). – specimen Aug 25 '21 at 10:21
  • 1
    @specimen FYI ServiceStack will no longer warn about missing properties on AutoQuery APIs by default from the [latest v5.12.1 on MyGet](https://docs.servicestack.net/myget) – mythz Aug 25 '21 at 10:41
  • 1
    If someone reads these comments: Look at the timestamp from when I posted the bug report/feature request (however you look at it), to when I got the first answer, then timestamp in comments, and eventually timestamp of updated framework code. Amazing! Add to that I'm in Time Zone UTC+1, which means I posted my question 05:50 New York time (where I think SS is located). – specimen Aug 25 '21 at 10:49
  • @specimen Used to be in NYC, before returning back to Australia 1-2 yrs ago. – mythz Aug 25 '21 at 10:51