Periodic 401 error causing calendar to desynchronize
sapphic-wallflower opened this issue · comments
Description
About a week or so after adding a calendar, I'll get an email from my ESP, saying the calendar has been deactivated and will no longer sync. See below.
We encountered some errors while syncing your calendar GO Calendar - Community Day.
Syncing to your GO Calendar - Community Day calendar has been disabled: [3EAFE4CA-7480-11EE-BA75-5E4721BC2B6F] An error occurred accessing your remote calendar GO Calendar - Community Day: 401 Unauthorized
I will then need to remove the calendar from my ESP, and add it again until the cycle repeats. The calendar will remain, but will never receive another update.
Version
n/a
Steps to Reproduce
- Create a FastMail account.
- Create a non-default calendar.
- Add any of the specific .ics files to your list of subscribed calendars.
- Wait ~7 days.
Screenshots
Missing Spotlight Hour, will not update after 401 error.
Device
n/a
Operating System
n/a
Additional Context
My ESP is Fastmail.
This is completely out of my hands I'm afraid, as I have no control over GitHub or FastMail's web servers to understand what could be causing a 401 between the two systems.
There should be no reason for a 401, as all asset links are public and static, and therefor shouldn't trigger an auth request on GitHub. The URL's provided for the calendar subscriptions are just the raw public static asset links.
My advice would be to take this up with FastMail's customer support and have them look into why their system is getting a 401 from a public static GitHub URL on a routine basis. 7 days seems like a weirdly routine window as well, my gut feeling is thinking some form of cache or automated job somewhere on FastMail's side.
Unfortunately I can't help on this one!
Hey @othyn,
I understand the issue has been closed already, but I wanted to update you with their reply.
Our developers have looked in to the task, and the issue appears to be on their end given it is a 401 error.
They've further explained the following:
If we look at the link, we can see it uses Amazon Web Services, and has authentication built into the query parameters. Of most interest is this: X-Amz-Expires=300.
Taking a look at their documentation, we can see this specifies how long the link will be valid for in seconds. So the link will only work for 5 minutes from creation.
I can tell when I'm going to get passed around to both providers, so I'm going to bow out of this one. Your service is great when it works (for me), and I'm sure a ton of people get use out of it. Maybe you can use this information to make your software better, maybe not. Good luck!
I can tell when I'm going to get passed around to both providers
Afraid you are. But its because I have no position of control here. None of the following is directed at you, but to explain the situation from a technical perspective and take an educated guess at what's going on.
I'm utilising GitHub to host the files, nothing complex or custom. The URL's are static, and every other calendar provider (Google, Apple, etc.) don't have this problem, presumably because they simply store the URL and periodically poll it to check for updates. Doing that will never trigger a 401 as its impossible, the URL is a static string with a fresh request on each poll to the URL to fetch the latest instance of the calendar file.
I have no idea what FastMail are doing, but it sounds really odd. Based on the fact they are getting a 401, and the fact that they're getting a X-Amz-Expires=300 header on the response, I'm guessing instead of simply storing the URL, they are doing something more complex and trying to store a direct link to the file from behind the static URL, which will expire as GitHub will need to expire their CDN cache on the file at some point and ensure that services aren't permanently using direct file links. Now, I have no idea how or why (or even if they are at all, as I'm only working on educated guesses here) FastMail are doing this. They have a static public URL that they can poll for a fresh copy of the file for the calendar that won't be subject to any expiration headers, as that would be daft for a static public URL such as the calendar link to have, for any repo. It would be like putting a link expiry on a GitHub release file. Its just a static URL string, its impossible.
This is a problem between GitHub and FastMail, and to me, it sounds like FastMail have a problem with their implementation of their fetch logic for their calendars. You'll have this problem with any other hosted calendar file on GitHub or any other CDN/web service, as FastMail are doing something funky on their backend.
Again, I could be completely wrong, but thats my best educated guess at what is going on.
Maybe you can use this information to make your software better, maybe not.
Sorry I couldn't be of more use, but just like you, I'm equally just a bystander in this problem. Its not my problem to solve.