Repository navigation
fix(calendar): prefer the destination provider for meeting generation - #62
Conversation
|
All contributors have signed the CLA. ✅ |
|
I have read the CLA Document and I hereby sign the CLA |
|
This repo's model isn't fully set up yet. OPENAI_COMPATIBLE_MODEL env var is required when the model is set to "openai-compatible/byok". set it to the model ID served by your OpenAI-compatible endpoint (e.g. a Cloudflare AI Gateway or DashScope model). see https://docs.pullfrog.com/openai-compatible for setup.
|
|
recheck |
|
Hi Marijn - quick heads-up beyond the review: your Sunday batch is the lead story in our v0.10.0 release announcement (ten PRs in sixteen minutes, CLA on all of them). We would name you by your GitHub handle with a link to your profile, nothing beyond what is public here. Cool with that, or prefer we keep it low-key? Either way the code stands on its own. Thanks again for the batch. - Wynne |

With more than one calendar provider connected, the meeting-link path can pick the first connection instead of the destination. For example, an older CalDAV connection can take precedence over a Google destination.
I changed the connected-provider lookup to prefer the destination, with creation time as a stable fallback. The test covers CalDAV connected before Google and switching the destination back. Calendar write routing is unchanged.
Validation:
go test ./...andmake buildpass.This is separate from #58: that issue is about moving or cancelling existing events after changing providers.