© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
1b1ed1a
(Get the code!)
Here's a dump of what I found out in case anyone else has ideas:
* There are plenty of subscriptions where the CAPTURED notification is handled without error in the logs, so either something about the state of the subscription or the server different.
* I can even post to the notification url given in the above oops and it works just fine https:/
* The fact that there is no log message before the oops suggests that we're not getting to the
subscription.
So I'm left thinking something temporal (a transaction rollback on the view? or something related to the timestamp used during _set_state?) is causing these few remaining notification 500s.
Of course, if we had tracebacks in the related oopses, things would be a lot simpler. At first I thought it was to do with the:
2011-04-17 14:37:46,144 - root - ERROR - Error when dumping OOPS 1933rangpur3
messages we were seeing in the log, but then, it's hard to tell, as we currently have r54 installed on the production server [1], and it was r56 that stopped this (incorrect) error message being printed for each oops [2].
[1] https:/
[2] https:/