0

I’m having a couple issues with Postgres timeouts in my Wallaby tests. The error I’m getting is:

[error] Postgrex.Protocol (#PID<0.349.0>) disconnected: ** (DBConnection.ConnectionError) owner #PID<0.566.0> timed out because it owned the connection for longer than 15000ms

It happens locally when I try to chain a click(button("Submit")) event (I think all the ones I’ve had issues with do a form submission, <a> links seems to work fine) with a CSS assertion like assert_has(link("Sign Out"). If I pass the session from the context instead of piping the two together it seems to be okay. However, it still fails on the CI server (Travis).

It kind of sounds like the issue described above (“often times in our test suites the error that an action is performed and one goes on to another page without waiting that the action completed, creating a race condition”), but it fails or succeeds consistently rather than being flaky so I’m wondering if there’s not something I’m missing.

Here’s the PR that’s failing, if you wanna see the actual code: https://github.com/solid-af/cheese_log/pull/18

I should also mention that (while testing locally) it looks like the assertion that’s failing after the timeout should have been successful. If I remove the explicit return of session in RegistrationPage.register_with, the line that’s failing is RegistrationPage.assert_registered(). I have screenshot_on_failure turned on. The screenshot from that shows the form filled out, but not submitted, while the manual take_screenshot() line above shows the home page with the “successfully registered” text. Super weird!

|> RegistrationPage.register_with(@valid_attrs)
|> take_screenshot()
|> RegistrationPage.assert_registered()

edit: though the issues I’m having locally seem to be unrelated to the issue I’m having on CI. As pointed out below, that is likely something do to with the connection staying logged in somehow.

marcdel
  • 23
  • 4

2 Answers2

0

The issue is not where you expect it to be. Assertion RegistrationPage.assert_registered() succeeds. You have issues signing out and the subsequent call to Page.click_sign_in() fails. Basically, your test stays logged in forever.

I have modified the code in sign_in_test.exs to visit a homepage and then take a screenshot:

  test "user can sign in", %{session: session} do
    session
    |> Page.visit_home_page()
    |> Page.click_sign_in()
    |> SignInPage.click_register_link()
    |> RegistrationPage.register_with(@valid_attrs)
    |> RegistrationPage.assert_registered()
    |> Page.click_sign_out()
    |> Page.visit_home_page()

    |> take_screenshot() # HERE

    |> Page.click_sign_in()
    |> SignInPage.sign_in_with(@valid_attrs)
    |> SignInPage.assert_signed_in()
  end

And the screenshot shows there is still “Sign Out” visible:

Screenshot after click_sign_out

Aleksei Matiushkin
  • 119,336
  • 10
  • 100
  • 160
  • Sorry, I made things unnecessarily confusing. I was testing locally by removing line 30 of registration_page.ex which explicitly returns the session. I believe you’re right that the CI issue may be a problem with my session plug or something rather than with my wallaby config. It looks like the other acceptance tests are passing there so it’s likely something to do with my auth plug or the associated logic. Thanks! – marcdel Dec 15 '17 at 11:18
-1

I have the same problem in test env. Add this in your config/test.exs file under data base config

ownership_timeout: 60_000

This should do the trick. The error you are getting is because by default the time set is 15000. So if any process takes longer than that Db throws an error.

script
  • 1,667
  • 1
  • 12
  • 24
  • Increasing any timeout value from 15s to 60s is insane. If anything successfully runs in more than 15s, it should be considering _failing_. – Aleksei Matiushkin Dec 15 '17 at 06:07
  • @mudasobwa if i want to seed data base with lot of entries i have to increase the time_out of the db. I am answering the question that he posted. – script Dec 15 '17 at 06:10
  • so don,t say things that you don't have any idea about. and 60 is just a value you can use timeout depend upon the requirement – script Dec 15 '17 at 06:10
  • Increasing a timeout is by no mean an appropriate solution and should never be suggested. Period. – Aleksei Matiushkin Dec 15 '17 at 06:11
  • the default for time_out initially is 5000 which then increased to 15000. Than go and ask jose valim that he is insane. period – script Dec 15 '17 at 06:14
  • Thanks for your answer. This is a super basic crud app with no seed data, so nothing takes nearly that long to load at the moment. I did, however, play with the `max_wait_time` config value, which determines how long to block waiting for an assertion to pass before failing, hoping to see if the actual issue was different. – marcdel Dec 15 '17 at 11:32