@topspin the language provided one essentially allows you to chain a bunch of ?. calls, such as a?.Child?.Child, which leaves you with either null or the final child type. You then often use ?? SomeDefault() ; to eliminate null if you have a default you want. What gets interesting with the one in the op is that you can bring multiple objects into the query, and use let and the select line to call basically any code you want along the way, and the end result will always be an empty list or one which contains the object you want to select, even if you're constructing that dependent on everything else not being null. The problem, other than the innate weirdness of it, is that in most cases, guarding against all those nulls explicitly may be better, if that's invalid input to whatever you're constructing. Which makes the primary use, imo, the optional construction of types with non nullable arguments.

@Gribnit said in Too many pumps: Although many frameworks do drain the input stream surprisingly early Yeah. Maybe. I forget what I eventually resulted to.

@magnusmaster Considering that your original post is about the HttpClient...

@Tsaukpaetra it's a rare case that most people will never encounter, so it's not surprising that you wouldn't know about it. This thread was a TIL.

@Parody Yeah, so, this is data we've had distributed through the state storage on a bunch of service fabric actors for a few months. I have yet to get to trying to address this, because it is depressing and not likely to go well.

So, I've ended up settling on an Azure Function, but because of some data concerns I still have a lot to learn. This should be interesting.

@jbert said in HttpClient gives me 405s: I have seen this status code a lot where a POST to e.g. http://localhost/customers replies with a redirect to https://localhost/customers after which the client would fall back to sending a GET request (I can't remember if the HTTP spec states anything about this). Since that sample route is only ever used to create a new instance of a record, the server would then reply with a HTTP 405 status code once the GET request hits it. The HTTP client would only give the HTTP 405 code instead of the original HTTP 302. You're better off using 303 (if you want to switch to a GET) or 307 (if you want the method preserved). HTTP 302 - Wikipedia And yes, some frameworks are nasty in what they do here (and some browsers were awful in their misinterpretations).

@dkf At least in the version of Word I had at the time — that was over 10 years ago — as best I can recall, that wasn't really possible. The picture could be positioned relative to the page — that's the way to get it to mostly work that I mentioned — but it was still anchored to the text — specifically, to the first paragraph on the page — and if an edit caused the text to move to the previous page, so did the picture. I could be misremembering — it has been more than 10 years — but I spent something like 14 months fighting this, so if there were any easy fix, I think I would have found it.

@dkf I managed to convince them that it's silly to allow these messages's content to vary in more than details, since they're in a user registration process. Averted.