Cal.com API endpoint missing (?)

[luckow]

I looked at https://git.cloudron.io/packages/calcom-app/-/blob/main/Dockerfile and realized that there is something configured with api/v2.

But: open https://cal.example.org/api/v2 only returns error 500 (after 10 seconds).

I have tested the official API of cal.com https://api.cal.com/v2/ and get a 200 OK.

A comparison of https://cal.com/docs/self-hosting/installation#api with /app/code/calcom/apps/web/app/api shows no env files.
Something is going wrong here.

[nebulon]

do you see any errors in the app logs about the 500 status?

[luckow]

no nothing. within the app, a curl http://localhost:3000/api/v2 throws a timeout.

[nebulon]

Trying to reproduce this. It is not clear why the app times out with a 500 but the api seems to be responding normally when the path has a trailling /

That just returns a redirect to /api/v2 which times out.

Apparently the API server of calcom is some standalone process, which is not even run in the package. Have to see how to get that going...

[nebulon]

New app package with the API endpoint enabled is out. This is a major version update, so requires manual intervention as a new api endpoint subdomain is now required.

[Gengar]

@nebulon What do you mean by manual intervention ?

We need to setup this new subdomain in the dns manually even if we have an api token to setup subdomains automatically ?

[nebulon]

Manual intervention due to the major package version update. This means the app does not automatically update.
The DNS setup will work according to how the domain is configured, so of course if an automated backend is used, this will handle the actual DNS setup.

[Gengar]

Okay thx a lot. I updated cal.com and in my case it should have been automated but I had to do it manually.

[luckow]

@nebulon
mh. API endpoint is not reliable. I have detected two errors in the logs:

read-only error

Apr 02 12:58:11 {"date":"Wed Apr 02 2025 11:58:11 GMT+0000 (Coordinated Universal Time)","error" {"code":"EROFS","errno":-30,"path":"./swagger/documentation.json","syscall":"unlink"},"level":"error","message":"unhandledRejection: EROFS: read-only file system, unlink './swagger/documentation.json'\nError: EROFS: read-only file system, unlink './swagger/documentation.json'\n at Object.unlinkSync (node:fs:1953:11)\n at generateSwagger (/app/code/calcom/apps/api/v2/dist/apps/api/v2/src/main.js:87:12)\n at run (/app/code/calcom/apps/api/v2/dist/apps/api/v2/src/main.js:24:14)\n at process.processTicksAndRejections (node:internal/process/task_queues:105:5)","os":{"loadavg":[1.76,1.55,1.57],"uptime":2270453.82},"process":{"argv":["/usr/local/node-22.14.0/bin/node","/app/code/calcom/apps/api/v2/dist/apps/api/v2/src/main.js"],"cwd":"/app/code/calcom/apps/api/v2","execPath":"/usr/local/node-22.14.0/bin/node","gid":0,"memoryUsage":{"arrayBuffers":138616,"external":3492265,"heapTotal":285544448,"heapUsed":264459784,"rss":388689920},"pid":41841,"uid":0,"version":"v22.14.0"},"rejection":true,"service":"cal-platform-api","stack":"Error: EROFS: read-only file system, unlink './swagger/documentation.json'\n at Object.unlinkSync (node:fs:1953:11)\n at generateSwagger (/app/code/calcom/apps/api/v2/dist/apps/api/v2/src/main.js:87:12)\n at run (/app/code/calcom/apps/api/v2/dist/apps/api/v2/src/main.js:24:14)\n at process.processTicksAndRejections (node:internal/process/task_queues:105:5)","timestamp":"2025-04-02 11:58:11.613","trace":[{"column":11,"file":"node:fs","function":"Object.unlinkSync","line":1953,"method":"unlinkSync","native":false},{"column":12,"file":"/app/code/calcom/apps/api/v2/dist/apps/api/v2/src/main.js","function":"generateSwagger","line":87,"method":null,"native":false},{"column":14,"file":"/app/code/calcom/apps/api/v2/dist/apps/api/v2/src/main.js","function":"run","line":24,"method":null,"native":false},{"column":5,"file":"node:internal/process/task_queues","function":"process.processTicksAndRejections","line":105,"method":"processTicksAndRejections","native":false}]}

socket hang up error

Apr 02 13:36:40 @calcom/web:start: Failed to proxy https://cal-api.example.com/api/v2 Error: socket hang up
Apr 02 13:36:40 @calcom/web:start: at TLSSocket.socketCloseListener (node:_http_client:491:27)
Apr 02 13:36:40 @calcom/web:start: at TLSSocket.emit (node:events:530:35)
Apr 02 13:36:40 @calcom/web:start: at node:net:351:12
Apr 02 13:36:40 @calcom/web:start: at TCP.done (node:_tls_wrap:650:7)
Apr 02 13:36:40 @calcom/web:start: at TCP.callbackTrampoline (node:internal/async_hooks:130:17) {
Apr 02 13:36:40 @calcom/web:start: code: 'ECONNRESET'
Apr 02 13:36:40 @calcom/web:start: }
Apr 02 13:36:40 @calcom/web:start: Error: socket hang up
Apr 02 13:36:40 @calcom/web:start: at TLSSocket.socketCloseListener (node:_http_client:491:27)
Apr 02 13:36:40 @calcom/web:start: at TLSSocket.emit (node:events:530:35)
Apr 02 13:36:40 @calcom/web:start: at node:net:351:12
Apr 02 13:36:40 @calcom/web:start: at TCP.done (node:_tls_wrap:650:7)
Apr 02 13:36:40 @calcom/web:start: at TCP.callbackTrampoline (node:internal/async_hooks:130:17) {
Apr 02 13:36:40 @calcom/web:start: code: 'ECONNRESET'
Apr 02 13:36:40 @calcom/web:start: }

The first two or three browser calls to the new api endpoint worked, but the following calls ended with a timeout. OK, technically they don't work because a 200 = Ok is missing. Instead I get a 502 on the bare domain.
https://cal-api.example.org

[nebulon]

"code":"EROFS","errno":-30,"path":"./swagger/documentation.json" so it tries to write some swagger docs files during API calls?

I haven't looked at their API docs or so, but this does sound wrong indeed.

Do you have example curl commands we could run to reproduce this?

[luckow]

https://api.cal.com/ -> 200
https://calcom-api.demo.cloudron.io/ -> 502

[Gengar]

And also it seems like since the update of the app the CPU usage has increased A LOT (green line and red line are two cal instances and blue line is the total)

@luckow Did you notice the same ?

[luckow]

@Gengar nope.

[Gengar]

@luckow Mhhh ok thank you for checking. I've set a limit on CPU usage now for those two instances of cal and it's better.

[nebulon]

It is still unclear to me what is happening. Calling the api does respond, but wrongly due to the app trying to rebuild the swagger documentation on every api call. Totally unclear why this is happening.

Once the filesystem is temporarily writeable, the api docs rebuilding does not fail but also never writes anything, however the node process goes into a 100% cpu occupying loop and never finishes.

[Gengar]

@nebulon Oh so there was something with the cpu. Interesting... Thank you for the new information nebulon

[nebulon]

I think I managed to fix this. Just released a new app package v2.0.1 for that.

[Gengar]

@nebulon thank you ! I'm going to update and test rn

Edit : I can confirm you solved the CPU 100% issue :

We can clearly see the result after the update