Unexpected Interaction Between Timeout Middleware and Persistent

[StevenXL]

Hi all,

I am experiencing some unexpected behavior between persistent and the wai-extra's timeout middleware.

In brief, I have instrumented a web application to return a 503 when a request takes longer than 5 seconds to complete. However, under certain scenarios, the application is returning a 500. I have included a script that consistently reproduces the problem on my machine, but I believe that timing is a large part of this issue and can therefore make reproducing the problem tricky.

I have included below some screenshots of the yesod logs and what the end-user experiences below, a screen recording showing that the issue is consistent (again, on my machine), and of the HTTP response.

consistent-failure.mov

A few things to note:

• The script requires postgres to be running via a docker command; command is in comments
• If I use SELECT pg_sleep(6); SELECT ?? FROM generate_series(1, 90000) AS ser(num) JOIN samples ON (TRUE)" I see the expected 503`
• I am using a stack resolver in the script, which should hopefully tie down the versions of all dependencies.

I am happy to provide more information if requested - I ignored the template for bug reports because I felt that the requested information was not relevant for this bug, but if I am wrong, I am happy to provide.

[parsonsmatt]

Since this is an asynchronous exception issue, I'm tempted to blame it on #1199. Can you try the patch in #1207 (or #1208 for persistent-2.10.5 or #1209 for persistent-2.11.0)?

To be totally clear, the problem is that you've got a 500 - timeout when you expect the error code to be a 503 - timeout? And this only happens when the timeout is a persistent action?

[StevenXL]

Hi Matt,

1. Yes, I am expecting a 503 because I am using the timeout middleware from wai-extra, which states that it will respond with a status503 in the case of a timeout.

2. Yes, this behavior only occurs within a persistent action. If I add a threadDelay instead (so that the persistent action never gets run), I see the expected 503.

As you suggested, I am trying to use the HEAD of persistent-2.11.0, but I am finding it difficult to tell a basic stack project to use that version of the package.

My stack.yaml looks like this:

resolver: lts-17.4

extra-deps:
  - git: https://github.com/yesodweb/persistent.git
    commit: b1e32adfe1da49cd9df997a13bd0c5b391486f5c

but when I run stack build I get an error:

Cloning b1e32adfe1da49cd9df997a13bd0c5b391486f5c from https://github.com/yesodweb/persistent.git
No cabal file found for Repo from https://github.com/yesodweb/persistent.git, commit b1e32adfe1da49cd9df997a13bd0c5b391486f5c

I've already asked for help in a few places so hopefully someone can tell me what I am doing wrong and I'll be able to respond back with the results of using the patched version.

[parsonsmatt]

Try using:

extra-deps:
  - git: ...
    commit: ...
    subdirs:
      - persistent

[StevenXL]

Try using:

extra-deps:
  - git: ...
    commit: ...
    subdirs:
      - persistent

Looks like that got me past my build problem.

I am, however, still experiencing the 500. Am I doing something wrong?

I'm attaching an archive of the full repo in case you are interested in reviewing the contents or reproducing it. Again, to have this fully working, you need to run the docker command in the Repro.hs file to set up a DB.