If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Unable to submit or delete event after leaving comment

NEW
Unassigned

Status

Webtools
Air Mozilla
P1
normal
3 years ago
3 years ago

People

(Reporter: mkelly, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

3 years ago
For the past two events I've submitted I've had trouble submitting or deleting them. Specifically:

1. Create event and fill out details as normal up to the summary page.
2. Enter a comment in the Additional Comments box (like "Please start recording 5 minutes after the hour") and click the Comment button.
3. After the page reloads for the submit, click the Submit for review button.

When I follow the steps above, a few things happen:

- Clicking the Submit for review button refreshes the event summary page, but does not change the event to submitted nor change anything about the event.
- Attempting to delete the event has the same result; page refreshes, no changes made, event is not deleted.
- The homepage shows a notification "Comment added but not emailed to producers because the event is not submitted." that can be dismissed while still on the page, but reappears if the page is reloaded.

https://air.mozilla.org/requests/993/summary/ is an example of an event stuck in this state. I cannot submit it nor can I delete it. Halp!
(Reporter)

Comment 1

3 years ago
After going back to the summary page after filing this bug, I'm now getting a 404; maybe the submit/delete are going through but taking a while to propagate to all the webheads or DB slaves or something?
(Reporter)

Comment 2

3 years ago
I'm also able to reproduce this without leaving a comment, as I just did with https://air.mozilla.org/requests/994/summary/. I'm unable to submit, but I won't mess with deleting it in case it eventually syncs up.
Component: Other → Air Mozilla
Product: Air Mozilla → Webtools
Version: unspecified → Trunk
Sounds similar to what Alinah reported last week.

I hate asking this question, but....

Can you reproduce this with a clean profile?
Flags: needinfo?(mkelly)
Priority: -- → P1
(Reporter)

Comment 4

3 years ago
(In reply to Richard A Milewski[:richard] from comment #3)
> Sounds similar to what Alinah reported last week.
> 
> I hate asking this question, but....
> 
> Can you reproduce this with a clean profile?

I can't! That's really odd. Worked fine on a fresh Firefox 36 profile. (https://air.mozilla.org/requests/995/summary/ is the test event I created). I'm able to submit and retract and submit comments with no issues.

For the record, I've been using Developer Edition with a profile that was created about 3 weeks ago.
Flags: needinfo?(mkelly)
(Reporter)

Comment 5

3 years ago
It may or may not be related, but I originally thought you meant to use a different AirMo account, so I attempted to sign in with a different email on my non-fresh profile, and login was silently failing. When I tried with the fresh profile I was able to see the message that the email I was trying to log in with wasn't vouched, whereas on my old profile I saw nothing. Weird.
(Reporter)

Comment 6

3 years ago
And just to be thorough, a fresh profile on Firefox Developer Edition also cannot reproduce the issue.
For what it's worth, when Alina got hit by this bizarre issue (she was able to submit her event using Safari) this wasn't the only bizarre thing that happened in her Firefox release. Afterwards, when viewing the event she spotted a typo which Richard fixed but when she refreshed the browser kept the old typo. There's no caching going on the event page and I could not reproduce it with my browser. It was as if her browser had cached some DOM rendering. 

I'm guessing the problem is gone now. Is it? If not, would you be able to use the Network panel to try to figure out which POST submissions your browser is sending to the server?
(Reporter)

Comment 8

3 years ago
I'm still getting the issue. Here's a pastebin of the request headers that got sent when I tried and failed to delete a video: https://pastebin.mozilla.org/8826012

However, it appears that the first time I submitted the deletion it worked, because I saw the video listing and the video was gone. But as soon as I refreshed it was back again.

The response to the failed POST I linked to was a 404: https://pastebin.mozilla.org/8826013

I'm wondering if maybe Zeus is caching a little too aggressively? All the pages with incorrect info on them have the X-Cache-Info: "cached" header, whereas any response I get without that seems to have accurate data. Sure enough, when I add ?foo to the end of my requests page or any other page with videos that should be deleted or submitted, I see the correct info.
You need to log in before you can comment on or make changes to this bug.