That "syncs once then stops" pattern everyone's mentioning really sticks out to me. I just set up a similar sync pipeline at my place and we got bit by the daily quota too, but ours failed for everyone at once.
Since you said your Terraform is standard, I'd double-check the OAuth consent screen in the GCP console directly. Our IaC was correct, but the published app name was different in the live console and it caused weird scoping issues for some internal user groups. Could that explain your split if some users auth'd before a console change?
Also, maybe a silly question, but did anyone check if the failing users all have their primary calendar in a different timezone? I saw a bug once where an API filter defaulted to UTC and silently dropped events.
Oh, the timezone bug is a sneaky one! We had an incident where a monitoring script filtered for "startTime > now()" but used local server time, while the API returned UTC. Half the team's alerts vanished silently.
Your point about the consent screen name is spot on. Even with perfect Terraform, if the live console has a typo or old name, it creates a separate internal OAuth client that new auth flows use. Users who authed before the drift keep working; new ones fail. It's a total headache.
Did you manage to catch your quota issue from the logs, or did you have to dig through the Google Cloud console graphs?
Dashboards or it didn't happen.
The real fun starts when you realize the "standard OAuth" setup is a myth. Every admin console has at least one legacy project with a zombie service account still clinging to quota.
>syncs once then stops
That's the Google quota hall of fame right there. But since your Terraform is pristine, have you actually watched the real-time quota graphs for *all* projects, not just the one you think you're using? The split failure screams that one of your OUs is hitting a different, depleted quota pool.
Fellow's support is slow because they're hoping you'll find the ghost project yourself. It's always in the console, never in the code.
been there, migrated that
The "standard OAuth" and "pristine Terraform" claims are what get you every time. You've ruled out the IaC, but that's exactly why you need to go look at the manual mess in your GCP console that the code doesn't control.
Since you're seeing a perfect 50/50 split, the quota theory is plausible, but it's not always a global limit. More likely, your org has multiple OAuth client IDs active from different projects or consent screen iterations. Users who authed with Client A hit quota pool A, users with Client B hit a different, exhausted pool B. That's the split.
Stop asking Fellow for known issues and start asking them for the specific OAuth client ID and Google API error code from their sync logs for one failing user. If they won't give you that, your ticket is stalled because they can't debug your workspace's OAuth sprawl either.