$ret check in core/PluginCallback.inc at line 64
"handles" the error by putting information in the
session and returning an error status for the AJAX
request. the error is now swallowed and not returned
to main.php.. therefore at the end of the request we
COMMIT instead of ROLLBACK.
Logged In: YES
user_id=42211
Two ways to fix this that I can see:
1. Check for $session->exists('core.error.code') in main.php
and if we see that, roll back.
2. do a rollbackTransaction in PluginCallback every place
where we put the error into the session.
Since PluginCallback is the only place that's doing
putInSession, I could go either way on this. But if we're
going to be doing more of this (and I suspect that we are)
then it probably makes sense to track it in main.php and
make it part of our process for error detection, even though
it's way harder to test.
Thoughts? I've mostly implemented #2 with tests so I can go
that way.
Logged In: YES
user_id=942712
My take on AdminPlugins is that we want to change it from
being an immediate view to an AJAX variation of controller /
view.
I don't want to keep using views for controller work in future.
For an immediate fix, I'm fine with approach 2., rolling
back in AdminPluginCallback on error.
Logged In: YES
user_id=70034
maybe rollback in putInSession (if storage is initialized
before we load up the session).. keep in mind you want to
rollback what happened up to this point, but you need to
commit the session change if you want the error info to be
available on the next request!
Logged In: YES
user_id=42211
Hm. Ok, I'm going to opt to do the rollback as soon as we
know that there's an error (ie, in every case right before
we call $status->putInSession). That way there are no
hidden dependencies. Later once a clear pattern emerges we
can refactor.