bjeanes
commented
4 years ago I think this is a false alarm. Closing while I continue to investigate and will re-open if need be.
Closed bjeanes closed 4 years ago
bjeanes
commented
4 years ago I think this is a false alarm. Closing while I continue to investigate and will re-open if need be.
bjeanes
commented
4 years ago Yes. Apologies for the runaround here. A painful interaction of circumstances led me to this situation:
before(:context) which polluted the DB, which then conflicted with the following testsauth.accounts table, which caused the issue to become visible.Specifically what through me for a loop was the COMMITs in the log/test.log file. This is because the before(:context) is simply running outside of any particular spec's transaction, but I didn't know from the log output that it wasn't coming from within a test. :man_facepalming:
Sorry again. I think I just got flashbacks to the other week tracking down open/closed transactions.
I am opening this as a placeholder while I try to dig into it. Understandably, these types of issues are very hard to nail down.
So far the primary thing (I think) I have determined is that the issue happens in the first test that runs after a test which purposefully causes an invalid authenticity token[1]. The invalid auth test causes a stack trace which looks like so:
(Of note here for
rodauth-railsis that exceptions raised from therails_controller_instanceare dumped as unstyled backtraces from the Rack app and not handled in an expected way, from a Rails perspective. I'm glad I know this now because I'll have to massage that).I don't know enough about how RSpec/Capybara/whatever works to have formed a great mental model of what's going awry here, but I have a fuzzy notion that the way in which this exception is raised essentially from within Rack middleware might be bypassing some necessary accounting on
sequel-activerecord_connection's part. Maybe? Does that sound plausible?Regardless, using a global
before(:example)hook in the tests to check the pristineness (pristinity?) of the DB, the next test to run has a dirty DB and thelog/test.logfile shows aCOMMITduring acreate_accountin Roda.NOTE: I am not totally confident my theory is correct here as I can't seem to reproduce it when just running the authentication token spec followed by any other spec. So something more might be at play, which I can't yet see...
[1]: We have a specific test for how we handle this as a common issue with mobile use on our app is that certain browsers (AFAICR just Safari on iOS) will sometimes evict the browser from memory while it is not the active app, which will clear session-lifetime cookies, but it will preserve the page. This causes regular form submissions with invalid auth tokens, and so we have extra behaviour here (redirect to login, flash message, including special handling for XHR requests).