For a repro, you can run the existing sample on the latest azure functions runtime. You will see exceptions traced after the line Executing ObjectResult, writing value of type 'Microsoft.AspNetCore.Http.Internal.DefaultHttpResponse'.. This happens because we return the context's HttpResponse back to azure functions where it is being treated as an object needing to be serialized.
I prepared a PR which addresses this with the minimal amount of changes by instead returning an IActionResult that does nothing. I assume this is ok for the azure function use case since the Giraffe/Saturn pipeline should handle everything needed to prepare the response to the client and we just want the azure functions runtime to pass the context back up the stack. If that assumption is off we may need to rethink what a Saturn binding means for azure functions.
Krzysztof-Cieslak
commented
5 years ago
For a repro, you can run the existing sample on the latest azure functions runtime. You will see exceptions traced after the line
Executing ObjectResult, writing value of type 'Microsoft.AspNetCore.Http.Internal.DefaultHttpResponse'.. This happens because we return the context's HttpResponse back to azure functions where it is being treated as an object needing to be serialized.Based on what I learned in https://github.com/Azure/azure-webjobs-sdk-extensions/issues/478 this was never really a supported approach in v2, though I am still not sure why exceptions weren't visible on previous v2 runtimes with this approach.
I prepared a PR which addresses this with the minimal amount of changes by instead returning an
IActionResultthat does nothing. I assume this is ok for the azure function use case since the Giraffe/Saturn pipeline should handle everything needed to prepare the response to the client and we just want the azure functions runtime to pass the context back up the stack. If that assumption is off we may need to rethink what a Saturn binding means for azure functions.