[Intermittent] Email preferences are not always saved
Opened this issue · 3 comments
FxA Affected versions:
- 1.251.3
Prerequisites:
- User is on the “Manage your Email Preferences”
Steps to reproduce:
- User checks some email sections;
- User clicks on the Save button;
- “Consider is done” messages is displayed;
- User clicks on the “Back to email preferences” link;
- User is now back on the “Manage your Email Preferences”;
- Email preferences are properly saved;
- Uncheck the emails checkboxes;
- Click the Save button;
- Click on the “Back to email preferences” link;
- Observe the checkboxes on the “Manage your Email Preferences”;
Expected results:
- Email preferences are properly saved;
Actual results:
- Email preferences are not properly saved;
Notes:
Thanks for reporting, I can reproduce this.
I've done some local testing on this and the issue is certainly intermittent, however I was able to debug a bit:
- As far as i can tell, the issue doesn't seem to be in bedrock's front-end sending stale data. I can see the correct newsletters in the POST request each time after updating.
- When the bug occurs, I can see the incorrect newsletters being returned in the basket API call when the page loads after clicking "back to email-preferences". Setting
{cache: 'no-store'}
in the fetch request does not seem to make any difference. Neither does hard force-refreshing the browser. - After a couple of minutes, refreshing the page again will suddenly return the updated data.
Given the above, might the issue be due to a delay somewhere when processing the initial preference change?
Yeah, the requests go in to a task queue, so the update won't always be immediate. In the past it's taken a few mins for things to work through the pipes.
Might be that we need to scale up the queue workers, but I also note that @robhudson is planning some work to replace the current task queue tooling with a different setup, so that might be a good time to revisit throughput