Cannot client.fetchCalendars();

[barrct]

We are working on trying to display calendar data to users and as this is my first time working with tsdav I'm sure that I'm missing something. Unfortunately, the error "Error: no account for fetchCalendars" doesn't really mean much and I can't see any error code lookups.

I have tried to add in "username: '@gmail.com'," to the DAVClient() call to see if it wanted the account name with the other credentials, but I have the same error.

Since I am not using a username/password, I am not getting any refresh token, but I was expecting that the access token would work for 60 mins based on the auth. I was going to worry about refreshing and cleaning after I had any data flowing in the first place.

What am I doing wrong?

    const client = new tsdav.DAVClient({
        serverUrl: 'https://apidata.googleusercontent.com/caldav/v2/',
        credentials: {
            tokenUrl: 'https://accounts.google.com/o/oauth2/token',
            refreshToken: <access token from oAuth initImplicitFlow>,
            clientId: <company clientid>,
            clientSecret: <company secret>,
        },
        authMethod: 'Oauth',
        defaultAccountType: 'caldav',
    });

    console.log('fetchCalendars');
    try {
        const calendars = await client.fetchCalendars();
        console.log(calendars);
    } catch (e) {
        console.log(e);
    }

Error message

2025-01-03T02:40:50.289Z	0e3fe1ba-61c0-4b9e-88a0-e601217e3e08	INFO	fetchCalendars
2025-01-03T02:40:50.290Z	0e3fe1ba-61c0-4b9e-88a0-e601217e3e08	INFO	Error: no account for fetchCalendars
    at fetchCalendars (/var/task/node_modules/tsdav/dist/tsdav.cjs.js:860:19)
    at /var/task/node_modules/tsdav/dist/tsdav.cjs.js:1375:12
    at DAVClient.fetchCalendars (/var/task/node_modules/tsdav/dist/tsdav.cjs.js:1751:131)
    at exports.handler (/var/task/index.js:93:40)
    at Runtime.handleOnceNonStreaming (file:///var/runtime/index.mjs:1173:29)

[barrct]

Alright, so I added the client.login() and it is missing multiple parameters.
Where is "homeUrl" found?

2025-01-05T23:47:04.925Z	449728c8-9b74-469a-a88f-d48d7eda1e3e	INFO	login
2025-01-05T23:47:05.995Z	449728c8-9b74-469a-a88f-d48d7eda1e3e	ERROR	Invoke Error 	{"errorType":"Error","errorMessage":"cannot find homeUrl","stack":["Error: cannot find homeUrl","    at fetchHomeUrl (/var/task/node_modules/tsdav/dist/tsdav.cjs.js:1291:15)","    at process.processTicksAndRejections (node:internal/process/task_queues:105:5)","    at async createAccount (/var/task/node_modules/tsdav/dist/tsdav.cjs.js:1312:26)","    at async DAVClient.login (/var/task/node_modules/tsdav/dist/tsdav.cjs.js:1659:15)","    at async exports.handler (/var/task/index.js:93:5)"]}

[barrct]

note: this is tsdav: 2.1.3

[barrct]

Alright, so I figured out how to get the refresh token by changing the auth code to get the code and then requesting the tokens but was still getting an error in tsDav in the login() function, 'cannot find homeUrl'.

Getting the refresh_token was not clearly defined in anything.

The final issue was that I had calendar.readonly, that is all that was needed. However, that seems to block parts of tsDav and throws the homeURL error. However, that error is extremely vague and makes it look like there is an issue in my code, that I have a bad key, missing a parameter, or incorrectly using tsDAV.

After hours of trying to figure out what I am doing wrong, looking for bugs in the auth and tsDAV, I found the response from propfind that reported an error from Google that I had no access to the data (because I only had events.read instead of full access.

I would highly recommend reporting the actual errors that the remote server is reporting rather than a vauge "no url" error override that does not help to debug any issues.

[natewill]

can you explain how you fixed this please?

[SwapnilSoni1999]

Even I'm facing same with apple calendar

[natelindev]

will fix the error reporting.

[garshythoel]

@natelindev this is also an issue with apple calendar - here is my sentry log where it's clear that it's a 503 outage from apple's side but not reported as that. this makes it hard to alert users if the issue is server side or user credentials side