throw an exception on id.get if session is not available

[iamkrillin]

Throw exception on id.get

• You've read the Contributor Guide and Code of Conduct.
• You've included unit or integration tests for your change, where applicable.
• You've included inline docs for your change, where applicable.
• There's an open issue for the PR that you are making. If you'd like to propose a new feature or change, please open an issue to discuss the change or find an existing issue.

Summary of the changes (Less than 80 chars)

Description

Throw an exception in DistributedSession.Id.Get if the session is not available

[dotnet-policy-service]

Thanks for your PR, @iamkrillin. Someone from the team will get assigned to your PR shortly and we'll get it reviewed.

[amcasey]

It looks like the unavailability of a session is already signalled by an empty Id. Is that not sufficient?

[iamkrillin]

The problem I was running into was two fold:

1. The documentation says the Id returned is unique, which strictly speaking, if there is a possibility for it to return "" is not always true, but the bigger problem was..
2. When using sqlserverdistributedcache, if there is a problem with the setup (server not available, table missing, etc). The error gets eaten then logged to the console (which is not ideal when using IIS hosting)

These two things combined lead to a scenario where things looked to be working, but were not working. When I was working on this PR I though it was better to throw an exception since that would make it very clear that things were not working, but returning null would also work

Either of these would be preferable to eating a error, then returning a value IMO

[amcasey]

I'm not actually familiar with this type, but the current behavior certainly appears to be intentional. If we were going to move to a model where it throws, wouldn't it make more sense to just add a throw in Loads catch block?

Similarly, it would have been easy to give each failed session its own guid, so I assume they were grouped together with the id "" on purpose. (Whether that purpose is valid, I have no idea, though it's a common enough pattern.)

[iamkrillin]

That's a fair enough point, I did consider adding a throw into the catch in Load, I ultimately decided against it since Load is called in many places and I wanted my change to be as small as possible.

[dotnet-policy-service]

Looks like this PR hasn't been active for some time and the codebase could have been changed in the meantime.
To make sure no conflicting changes have occurred, please rerun validation before merging. You can do this by leaving an /azp run comment here (requires commit rights), or by simply closing and reopening.

[amcasey]

I was hoping an expert would chime in, but I'm not sure there is one for this type. 😆

Barring that, I think I'd prefer to just set it to null, rather than string.Empty in Load, which should cause it to use a fresh guid. Having said that, I can also see the value in just leaving it. If there is a session ID and it just couldn't be loaded, assigning a fresh one is a little strange. It looks like the expectation of the API is that the other properties will be disregarded if IsAvailable is false.

If you need more explicit error behavior in your app, do you have the option of either checking IsAvailable or switching to LoadAsync, which appears to throw when you want it to?

[iamkrillin]

I changed my application to check IsAvailable before opening this pull request, but figured if this behavior impacted me, perhaps it is impacting others. My Application was checking for null before as an error condition so that makes me think at some point in the past perhaps this API returned null in that scenario. My application has been around since .net 3 and is being updated to .net core so it may have been long ago.

[amcasey]

if this behavior impacted me, perhaps it is impacting others

Thanks for taking time to contribute! 😄

it may have been long ago

It certainly seems possible that the sentinel used to be null and changed to string.Empty sometime in the last decade. If we were designing the API now, I think there would be a strong argument in favor of making it throw. In fact, I'm guessing that did actually happen with LoadAsync was added.

In my personal opinion, the best way forward would be to update the doc comments to explain that IsAvailable should be called before Id, etc. I would also consider having Load set it to null to cause a new ID to be generated, though I think the value of that is diminished pretty substantially if the check-IsAvailable-first convention is made explicit.