API always returns 304 as response from PUT request

[lholman]

So, the API documentation has smoked out a few issues.
Taking a look at http://lloydstone.github.io/femah/api.html#UpdateAFeatureSwitch you can see that regardless of whether the feature switch is modified a 304 'Not Modified' is returned, you can check here before and after running the code.

[lholman]

AHHHHHHHhhhhhh, tearing my hair out.

Skype conversation below between @hotstone and I.

[16:38:41] Lloyd Holman: So, how can we provide better logging. I mean, I want to add logging around this methodhttps://github.com/lloydstone/femah/blob/master/Femah.Core/Api/ApiResponseBuilder.cs#L77
[16:39:21] Lloyd Holman: It's not doing what I want and always bailing out at https://github.com/lloydstone/femah/blob/master/Femah.Core/Api/ApiResponseBuilder.cs#L123 during a PUT, although all unit tests are working correctly
[16:40:05] Matt Hotstone: Hmm, maybe we could allow a logger to be injected - add it to the config? .WithLogger( myLogger) ?
[16:40:08] Lloyd Holman: Hook in to the hosting applications logging framework of choice, starting by supporting elmah?
[16:40:21] Lloyd Holman: ;) snap, you said it much more eloquently
[16:41:03] Matt Hotstone: Ha ha - great minds! :)
[16:41:34] Lloyd Holman: It's really weird as the PUT request is updating the entity, then fails on the post check on https://github.com/lloydstone/femah/blob/master/Femah.Core/Api/ApiResponseBuilder.cs#L111
[16:42:21] Lloyd Holman: Am I doing something silly with reference types or something, I can't right, c# is by default value types, yeah?
[16:42:46] Lloyd Holman: I can reproduce locally when curl'ing the host app
[16:42:52] Lloyd Holman: But unit tests work

So, we need better, logging, I'm blind to this issue and the alternative is.

1. Compile femah
2. Produce a NuGet package (ok, that's all one step in the build)
3. Manually update the reference in femah.examples
4. Try again and guess, no debugging in to femah source.

Nasty, nasty, nasty, bugger, maybe we need to do this now http://docs.nuget.org/docs/creating-packages/creating-and-publishing-a-symbol-package and create a symbol package so we can debug into Femah from the hosting app straight away?

[lholman]

Right, I completed #74 and had the culprit within 30 mins.
It turns out that https://github.com/lloydstone/femah/blob/master/Femah.Core/Api/ApiResponseBuilder.cs#L111 is failing the Equals comparison here https://github.com/lloydstone/femah/blob/master/Femah.Core/FeatureSwitchTypes/FeatureSwitchBase.cs#L96 on the FeatureType as the updatedFeatureSwitchState object returned from the provider (being compared) is providing the shortened FeatureType as opposed to the fully qualified FeatureType passed in in the API request, as can be seen below.

Furthermore, the reason we're not seeing unit tests fail is due to mocking out of the provider, which is ultimately correct as at that point we're not testing the providers. Some unit tests and fix on its way.

[lholman]

As we can see from the below we now get an HTTP 200 and the updated object returned in the body from a PUT request updating a featureswitch.

However, I'm still seeing an error with returning the current state of the object if a 304 is legitimately returned, (see below), I feel this is more something around #70

To do

• Publish updated Nuget package (including the above commits)
• Manually update femah.examples reference to the new Nuget package
• Deploy femah.examples to Azure

[lholman]

Issue deploying to Azure due to nuget.org being a dick.
https://nuget.codeplex.com/workitem/4110?FocusElement=CommentTextBox