Do you have a sample app to reproduce?
-
-
Replying to @sgrif
Not at the moment. Didn't quite go down that path b/c figured I was missing something obvious.
1 reply 0 retweets 0 likes -
Replying to @brandonhilkert
That would be my guess, but I can't tell you what it is without code
1 reply 0 retweets 0 likes -
Replying to @sgrif
Should i expect system tests to log to logs/test.log, or is this a totally separate thing?
1 reply 1 retweet 0 likes -
Replying to @brandonhilkert
I would expect them to log to the same place but TBH I don't know off the top of my head
1 reply 0 retweets 0 likes -
Replying to @sgrif
Looks like a new app behaves normally. The object_id of current_transaction shows the same ID in every view template in diff. test. Weird?
2 replies 0 retweets 0 likes -
Replying to @brandonhilkert
If you're able to create a minimal repro I will look into it.
1 reply 0 retweets 0 likes -
Replying to @sgrif
That's the prob. A fresh 5.1 app has same transaction object_id in test and view, but our app has different between test and view.
2 replies 0 retweets 0 likes -
Replying to @brandonhilkert
Right, so the thing is to figure out what's different in your app and add that to the repro
1 reply 0 retweets 0 likes -
Replying to @sgrif
Turns out puma was booting in cluster model causing it to created a uniq connection pool based on the fact that the PID was different.
1 reply 0 retweets 0 likes
Is that something we can easily detect/error on?
-
-
Replying to @sgrif
The only thing that comes to mind is search for a hardcoded puma config and inspect the workers method. It's loaded as a proc in Rails.
0 replies 0 retweets 0 likesThanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.