Log super-fast import timeouts

[Jeroen T. Vermeulen]

We regularly either have problems with the super-fast imports, or suspect we have problems with super-fast imports but aren't really sure.

We should log timeouts in ExistingPOFileInDatabase, so we know when this happens. The Recife model makes this cache a lot simpler, so the problem may just disappear.

[Jeroen T. Vermeulen (jtv)]

Ah, just found that there is a unit test for this class. The absence of the class from its __all__ misled me (the test imports it even though it's not in __all__). We do seem to need more thorough testing though, and some form of notification about the timeouts.

[Данило Шеган (danilo)]

Do scripts actually have timeouts?

[Jeroen T. Vermeulen (jtv)]

Most don't, but this one does. Somebody called Danilo something-or-other added a query timeout in ExistingPOFileInDatabase to stop a particular operational problem we were having at the time.

[Данило Шеган (danilo)]

Damn that guy.

Though indeed, it'd probably be good to log that one. Not sure how'd we tie it in into the regular timeout infrastructure (if at all), but it'd be good to know when this query starts failing.

[Jeroen T. Vermeulen (jtv)]

In this particular case I wouldn't invest into fancy reporting just yet. The Recife change may have eliminated any remaining instances of the timeout.

I'd just log a message, let the thing run for a while, and then see what follow-up is appropriate. Chances are that either we can remove the query timeout now, or we'll find it easier to diagnose the problem.