Redirected to generic Bango error page on cancel

RESOLVED FIXED in 2013-01-17


6 years ago
6 years ago


(Reporter: kumar, Assigned: Steve Ruston)


Mac OS X


In Andy's setup he can produce an error where Bango redirects to a generic error URL ( instead of the one configued by the Billing Configuration API call.

He sees the confirmation page then clicks cancel and is redirected to the wrong place.

Example URL:

Example SOAP request:

10:34:1358361274 suds.client:DEBUG sending to (
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:ns0="" xmlns:ns1="com.bango.webservices.billingconfiguration" xmlns:xsi="" xmlns:SOAP-ENV="">
            <ns1:pageTitle>Test App (foosdfpsdfyasdad)</ns1:pageTitle>
</SOAP-ENV:Envelope> :/Users/andy/.virtualenvs/solitude/lib/python2.6/site-packages/suds/
Blocks: 775802
Priority: -- → P1
Assignee: nobody → sruston
Target Milestone: --- → 2013-01-17

Comment 1

6 years ago
Quick explanation of the cause of the issue: Bango runs mainly on MS tech, and all web apps run on IIS. IIS allows webapps to be assigned to a 'app pool'. All apps in a app pool share the same worker process, and as such any app in the pool can cause an issue that can prompt the pool to need to be recycled (clearly multiple apps per app pool is not recommended, and won't be the case, for 'live' services). 

Anyway, we use the session to hold the detail of the current moz request (which allows state to be maintained between http backwards and forwards). When a app pool is recycled, all sessions are lost.  The reason for the above recycle was due to another app in the same pool exceeding the execution time.

Currently our handling of sessions being unavailable is pretty basis (if session is null redirect to hardcoded url), so I suggest we make this smarter (we could look up the correct error from the billing config id for example).

My question is, if everything has melted and we can retrieve the url, what should be the worse case behavior? I guess a hard-coded url isnt useful, a 500 status code, maybe? 

While in development, what would be useful is a bango hosted page that shows what the error query string is so we can at least see it. In production, you may want to make it a 500 Internal Error so that the info can be fetched from a log.
Keir, thanks for the insight. This seems to explain the random errors. However, Andy hits this error every single time :( Is there any way to look up the config ID to see if there is another error at work?
The cancel button is redirecting to our pre-configured error page now, thanks!
Last Resolved: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.