-
Notifications
You must be signed in to change notification settings - Fork 57
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Send message confirmation issues #75
Comments
I'm wondering if it's a timeout issue? Here's how we deal with this on the action center side: if there's no CAPTCHA, we just assume success. Because sometimes its a fail (and someone will deal with that via a delayedjob), and other times its a success, but then our assumption is correct. Can we do the same for DIO? |
We currently don't have a way of handling server errors in our send message callback (lines 122-126 in https://github.com/EFForg/democracy.io/blob/master/www/js/controllers/message-form.js). In the case of an error we just set the 'sending' boolean to false and show the form again. If it's a timeout issue, would we get an explicit server error passed through our callback? If so, forwarding for non captcha messages is easy. Any thoughts on the message to display for captcha-required messages? |
Yeah I think then that either an error or timeout is causing the problem, since showing the message form again is exactly what's happening. I'm not sure if we'd get an explicit error for a callback. It might be a 504? I think we should probably increase the timeout length to around 90 seconds (I'm pretty sure you can do this in Angular), and also assume success if there are no captchas to wait for and move people instantly to the "thanks" screen. |
I'm a little wary about auto-forwarding to the "thanks" screen - if there's an issue with our server or we can't reach PotC then we shouldn't let the user think the message has been sent. If we know the message reaches PotC, then I think it's okay to send them onward. Is there an easy way to pass that through to our callback from the server side? cc: @l12s I'm not sure how a timeout issue would be causing the sending boolean to flip - it would have to trigger the callback, right? |
If we can't reach the PotC server we won't be able to properly render the contact form in the first place, right? We need to ping PotC know what form fields to show the user. I think as long as we don't get a 500 or 400 error from the PotC within a second, we should just assume the message is being sent. We can continue to wait if there is a captcha to show the user. We're getting so many emails about this, I really think we should apply a hot-fix as soon as we can. |
Temporary fix with this commit: 2b18749 It still relies on the callback being hit so it won't be an instant forward on to the thanks page. I think a more permanent solution should involve the server side logic |
Great, thanks for doing that. The tricky things about changes to the API are that they affect lots of other org's implementations, so we need to make sure we get it right. What's the best solution is that we can suggest to @legind? The server could send a temporary "in process" message and then the client could start long-polling? |
I'm getting lots and lots of these, so I'll document them all here. A bit hard to tell exactly what is happening.
2:
3:
4:
5:
6:
7:
8:
9:
@randylubin I think you did most of the work on this step, could you take a look and see if you can figure it out.
The text was updated successfully, but these errors were encountered: