Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Do not treat lack of retrieval of session data as an exception #1275

Open
xsawyerx opened this issue Oct 13, 2016 · 3 comments
Open

Do not treat lack of retrieval of session data as an exception #1275

xsawyerx opened this issue Oct 13, 2016 · 3 comments

Comments

@xsawyerx
Copy link
Member

Right now we throw an error when we can't retrieve. Since not being able to retrieve does happen, we actually then test for it to not throw an error. This is broken.

@xsawyerx xsawyerx added the Bug label Oct 13, 2016
@veryrusty
Copy link
Member

At a quick look; I'd suggest:

_retrieve should return

  • the hashref of data if successful,
  • die on error if something went wrong (eg deserialisation of data fails), or
  • just return if there was nothing to retrieve.

A quick scan of CPAN pointed that the DBIC and CGISession session classes are the only non-core session implementations that are likely to need updating for such a change.
(Will need to do another check later..)

@demerphq
Copy link
Contributor

re: veryrusty

FWIW, what you describe is what I would have expected, and sounds like a good change.

Yves

@xsawyerx xsawyerx added this to the 0.205000 milestone Nov 6, 2016
@xsawyerx
Copy link
Member Author

I started looking into this and thought the first, simplest act would be to simply stop catching all retrieve calls again (since we're already catching inside retrieve all calls to _retrieve, the session retrieval method). Then I realized that means we won't handle any crashes from hooks, which are not guarded.

We're catching twice here because we want to be able to run the after hook, even if the retrieval failed. Then we need to catch again, to make sure we handle possible after hook crashes. But the weird part is that we do ignore any crashes of the session retrieval anyway.

I looked at handling of before/after of a route execution, in which case we do eval the before, we eval the route execution, but we do not eval the after. This suggests we want to run the route, even if we crash during the before, and we want to run the after, even if we crash in the route, but if we crash in the after, screw it, and make it crash everything.

If we want to have the same behavior here, we should remove the eval for the retrieve from Dancer2::Core::App. The _retrieval call within the retrieve method (inside Dancer2::Core::Role::SessionFactory) already has an eval, but the before hook doesn't have one, so we will need to add one there.

A question to @demerphq: All eval calls in Dancer2::Core::App call $EVAL_SHIM, but the evals in Dancer2::Core::Role::SessionFactory do not call it. Should they? What's the difference?

@xsawyerx xsawyerx removed this from the 2017-01-16 milestone Mar 7, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants