Start from Part 1 of the series if you missed the previous episodes.

Anything that can go wrong, will go wrong.

While writing the integrations for my Not-An-Alarm solution, I’m suddenly hit by friendly fire. Some of my tasks are clearly missing from the responses I get from the Google Tasks API, casting a shadow on the whole project.

After half a day of tinkering, and swearing in the most creative ways, I figure out it’s some of the periodic/repetitive tasks that are missing from the list. Difficult to pin-point which tasks exactly, but a quick web search solves the mystery.

There is apparently a well-known issue in the Google Tasks API. Its ramifications are clear: when dealing with repetitive tasks created earlier than 30 days, these tasks mysteriously vanish from API queries. Quite frustrating, to be honest! This is the description from the official Google Issuetracker: “after a few instances of a repeating task […] further instances stop appearing in the list of tasks”. What the…

Despite my enthusiasm to leverage the Google Tasks API for retrieving comprehensive data, this issue really disrupts the flow. Interestingly, when accessing tasks through the Google Calendar web UI, things look quite different. All recurring tasks, regardless of their age, elegantly reveal themselves. This contrast suggests Google might be using a private API, rather than the public one, for internal functions.

My quest for a workaround leads to investigate every single network call that is fired from my browser when opening the calendar. The URL it communicates with unravels the truth: Google Calendar accesses the internal Google API through a specific call to an internal ‘TasksApiService’.

🎵 Here’s my URL, so call me maybe:

curl 'https://tasks-pa.clients6.google.com/$rpc/google.internal.tasks.v1.TasksApiService/Sync' \
  -H 'authority: tasks-pa.clients6.google.com' \
  -H 'content-type: application/json+protobuf' \
  -H 'cookie: [tokens and stuff] \
  -H 'origin: https://calendar.google.com' \
  -H 'referer: https://calendar.google.com/' \
[user agent, api keys and othe random stuff]
  --data-raw '[[[[null,[]],[[]],[null,null,[]],[null,null,null,[]],[null,null,null,null,null,[]],[null,null,null,null,[null,null,[null,1,null,1,1,1]]],[null,null,null,null,[null,null,[1,null,null,1,1,1]]]],[]],null,[null,["[my Google USER ID]"]],null,["VkrxDO9edRMMw6C9",[2,4,"calendar.web_20231214.09_p0","prod-00-eu.web",3,5,2,null,1]]]' \
  --compressed

Not the clearest structure, but I guess one could figure it out, if they really wanted. And it goes without saying that building a solution on this would most likely break Google’s Terms of Service.

Can you hear it? It’s the siren call of screen scraping! We’ve all been there.

I start contemplating the use of Puppeteer or a Selenium scripts running within a headless Chrome instance. Picture a containerized setup, automated to log into my Google account, navigate to my Google Calendar, and screen scrape each bit and piece of vital information.

This approach, although tantalizing, brings a complexity that might overshadow the primary goal: having a functional PoC within a week. While the idea itself holds promise, setting up this elaborate choreography demands a significant investment of time and resources.

For the sake of maintaining focus, I opt to temporarily shelve this appealing side-track. However, I wouldn’t dismiss this idea entirely. It remains an option, perhaps for future iterations or explorations once the foundational PoC for Not-An-Alarm is in place.

For now, I anchor myself back to the core: my PoC for Not-An-Alarm. However, leaving breadcrumbs to this Google issue could offer a beacon for others navigating similar waters.

Navigating through such hurdles might slow the pace, but it seldom halts the journey. As I refocus on the PoC, the workaround for this Google Tasks API hiccup continues to simmer in the background, awaiting its turn in the spotlight.

Stay tuned for the final chapter!

1 thought on “Not-an-Alarm – Part 4/5 – Bug in the Google Tasks API

Leave a Reply