[ActivityWatch] Error while sending heartbeat

[dariusj18]

Not much more information, Developer tools console has three related errors:

[ActivityWatch] Error while sending heartbeat
onDidChangeNotification @ /C:/Program Files/Mi…esktop.main.js:2855

[Extension Host] [ActivityWatch][handleError] Error while sending heartbeat
t.log @ /C:/Program Files/Mi…desktop.main.js:262

[Extension Host] sendHeartbeat error: undefined
t.log @ /C:/Program Files/Mi…desktop.main.js:262

But a lot of logs for seeming successful sends

console.ts:137 [Extension Host] Sent heartbeat Object

[sebbdk]

Getting and error that seems similar to this, and the timing of this issue seems to match'ish.
I started getting this yesterday.

tried re-installing the extension, but no dice.

Addendum:
Also tried running the reload command.

[hmhka]

Have the same issue

[johan-bjareholt]

[Extension Host] sendHeartbeat error: undefined
t.log @ /C:/Program Files/Mi…desktop.main.js:262

That's unfortunate, we should never send something undefined to sendHeartbeat. Maybe vscode has changed their API somehow?

Do you have logs which are not minimized? The path to the source file is just a single row rather than multiple as well as hiding information inside the "..."

[dariusj18]

Now I seem to get this error, however I don't have any problem accessing Activity watch web UI, nor does my Activity watch Web Watcher seem to have an issue. To note, I am on a VPN using Cisco AnyConnect. This may or not be connected to the original issue.

[Extension Host] [ActivityWatch][handleError] Couldn't create Bucket. Please make sure the server is running properly and then run the [Reload ActivityWatch] command.
t.log @ console.ts:137
$logExtensionHostMessage @ mainThreadConsole.ts:39
_doInvokeHandler @ rpcProtocol.ts:402
_invokeHandler @ rpcProtocol.ts:387
_receiveRequest @ rpcProtocol.ts:303
_receiveOneMessage @ rpcProtocol.ts:230
(anonymous) @ rpcProtocol.ts:105
fire @ event.ts:587
fire @ ipc.net.ts:453
_receiveMessage @ ipc.net.ts:733
(anonymous) @ ipc.net.ts:592
fire @ event.ts:587
acceptChunk @ ipc.net.ts:239
(anonymous) @ ipc.net.ts:200
t @ ipc.net.ts:28
emit @ events.js:203
addChunk @ _stream_readable.js:295
readableAddChunk @ _stream_readable.js:276
Readable.push @ _stream_readable.js:210
onStreamRead @ internal/stream_base_commons.js:166

notificationsAlerts.ts:40 [ActivityWatch] Couldn't create Bucket. Please make sure the server is running properly and then run the [Reload ActivityWatch] command.
onDidChangeNotification @ notificationsAlerts.ts:40
(anonymous) @ notificationsAlerts.ts:26
fire @ event.ts:587
addNotification @ notifications.ts:207
notify @ notificationService.ts:106
(anonymous) @ mainThreadMessageService.ts:83
_showMessage @ mainThreadMessageService.ts:44
$showMessage @ mainThreadMessageService.ts:38
_doInvokeHandler @ rpcProtocol.ts:402
_invokeHandler @ rpcProtocol.ts:387
_receiveRequest @ rpcProtocol.ts:303
_receiveOneMessage @ rpcProtocol.ts:230
(anonymous) @ rpcProtocol.ts:105
fire @ event.ts:587
fire @ ipc.net.ts:453
_receiveMessage @ ipc.net.ts:733
(anonymous) @ ipc.net.ts:592
fire @ event.ts:587
acceptChunk @ ipc.net.ts:239
(anonymous) @ ipc.net.ts:200
t @ ipc.net.ts:28
emit @ events.js:203
addChunk @ _stream_readable.js:295
readableAddChunk @ _stream_readable.js:276
Readable.push @ _stream_readable.js:210
onStreamRead @ internal/stream_base_commons.js:166

[Extension Host] Error: timeout of 10000ms exceeded at createError (c:\Users\USERNAME\.vscode\extensions\lindraupe.aw-watcher-vscode-0.4.0\node_modules\axios\lib\core\createError.js:16:15) at Timeout.handleRequestTimeout [as _onTimeout] (c:\Users\USERNAME\.vscode\extensions\lindraupe.aw-watcher-vscode-0.4.0\node_modules\axios\lib\adapters\http.js:216:16) at listOnTimeout (internal/timers.js:531:17) at processTimers (internal/timers.js:475:7)
t.log @ console.ts:137
$logExtensionHostMessage @ mainThreadConsole.ts:39
_doInvokeHandler @ rpcProtocol.ts:402
_invokeHandler @ rpcProtocol.ts:387
_receiveRequest @ rpcProtocol.ts:303
_receiveOneMessage @ rpcProtocol.ts:230
(anonymous) @ rpcProtocol.ts:105
fire @ event.ts:587
fire @ ipc.net.ts:453
_receiveMessage @ ipc.net.ts:733
(anonymous) @ ipc.net.ts:592
fire @ event.ts:587
acceptChunk @ ipc.net.ts:239
(anonymous) @ ipc.net.ts:200
t @ ipc.net.ts:28
emit @ events.js:203
addChunk @ _stream_readable.js:295
readableAddChunk @ _stream_readable.js:276
Readable.push @ _stream_readable.js:210
onStreamRead @ internal/stream_base_commons.js:166

[johan-bjareholt]

VPNs might indeed break activitywatch. Could you shortly disable it just to see if it works?

It is possible to explicitly tell programs to ignore the proxy settings, but I'm not sure how to do that for vscode specifically.

[bddckr]

I have this issue and am not using any VPN. If there is something we can grab to help with this (logs, where?) let us know!

[johan-bjareholt]

The log above just says that it cannot connect to aw-server (running on localhost:5600) so it's clear what the issue is, the question is what keeps it from connecting.

[dariusj18]

Tried off of VPN, same error.

[lironesamoun]

Just installed it and get the same error as well.

[johan-bjareholt]

I tried to reproduce this today on my machine but was not able to, so there is some difference between platforms.
For all of you who have this issue, could you answer the following questions:

• What OS do you use? (Windows, macOS, Linux?)
• Do you use aw-server or aw-server-rust?
• Export your aw-watcher-vscode bucket, delete the bucket, stop vscode, delete your aw-watcher-vscode bucket and start vscode again
  • Does the bucket get created again? If it does, are there any events in the bucket?
• When does the watcher work or not?
  • Does it never successfully send any events at all? If it occasionaly works, can you find a pattern of when it does or doesn't work?

[Koushikphy]

I'm using windows 10 with aw-server (not rust). I checked again after deleting the buckets. It seems the problem still occurs but it also send heartbeats successfully sometimes, but most of the time it results in error. I might need to learn a things or two about the development of vs code extension to debug this problem for my machine.

[Koushikphy]

Adding to my last comment, I checked the extension a little. All I could trace back is sometime the axios post method doesn't get any response form the server and a Error: timeout of 10000ms exceeded is thrown. This happens here

https://github.com/ActivityWatch/aw-client-js/blob/f9d37d9f499f2bc84dd9f03532d4a7ece94b07a4/src/aw-client.ts#L189-L196

and here,

https://github.com/ActivityWatch/aw-client-js/blob/f9d37d9f499f2bc84dd9f03532d4a7ece94b07a4/src/aw-client.ts#L77-L81

[johan-bjareholt]

Hm, strange that aw-server doesn't respond in 10 seconds.

We could update to latest aw-client-js which is probably a good idea anyway, might or might not fix the issue. The new version does increase the default timeout to 30s though so if it fixes the problem it might be either because the root cause is fixed or because the timeout simply makes the issue occur less often.

[Koushikphy]

For now I have made this workaround, though its preety bad programming wise but it gets the job done. Provided the server is actually running and well and error is just a random no response event, we can try again if the error happens. For this I have called this method

aw-watcher-vscode/src/extension.ts

Line 60 in c7aa891

public init() {

again if the error is triggered for initial bucket creation/checking.

and silenced this

aw-watcher-vscode/src/extension.ts

Line 120 in c7aa891

this._handleError('Error while sending heartbeat', true);

notification line (making it false), so it does not bother the user if a heartbeat is failed to send. Preety messy but works

[johan-bjareholt]

The first change sounds good, recreating the bucket if it fails until it succeeds.

The second change only silences the issue rather than fixing anything, so that's not a good idea in my opinion.

[Koushikphy]

The heartbeat gets stacked, so if it fails to send one moment then it will be sent it in next successful try. That's why I silenced the notification. It's working for a last couple of days properly.
I'm also not a fan of this idea. What if there's is really some problem with the aw-server. There should be some proper approach to handle this problem

[johan-bjareholt]

I realized that it might be because of aw-client-js not supporting pre-merge heartbeats which is only supported on aw-client-python right now.
I can see that most people having the issue report it on Windows where heartbeat performance is very bad in comparison to macOS and Linux. The switch to aw-server-rust will likely also fix the issue.

[ErikBjare]

@johan-bjareholt That doesn't explain why it only started happening recently though (it seems anyway). I assumed something happened in a recent version of VSCode.

[johan-bjareholt]

@ErikBjare Well, at least it's easy to test which one it is. So if someone who had this issue, could you test it with aw-server-rust and see if it works better?

[Drarig29]

@ErikBjare Well, at least it's easy to test which one it is. So if someone who had this issue, could you test it with aw-server-rust and see if it works better?

I just tried it. I still have the same error, but it doesn't happen much.

[dividedby-0]

Reporting same issue here with extension v0.5.0 and vscode v1.58.2

[ghost]

@johan-bjareholt
IMPORTANT UPDATE: this error occurs when I visualize my editor activity in the dashboard and If I quit ActivityWatch in the tray and then reopen it, the extension goes back to working by simply reloading ActivityWatch. I can reproduce the issue as many times I want.

After investigating it seems the issue is with post methods themselves, it is not receiving a response.

[johan-bjareholt]

@iDevLP If the server is not responding it's because it's busy handling some other large request. Could you investigate what request that is? Maybe use Wireshark or if it's a request from the web-ui you could look at the Firefox/Chrome debug network tab with F12.

[ghost]

@johan-bjareholt Hello, I think I found the root cause and I explained it here ActivityWatch/activitywatch#664

[ghost]

The issue seems with aw-server itself when a browser connects to it. if you open the dashboard, the post methods never work again until you close the dashboard and the browser

I just found a workaroud for this issue until it gets fixed. if you opened the dashboard, just close the browser. don't open the dashboard if you are using vscode or you can open it and close it alongside the browser quickly before post requests from the extension reaches timeout.

if you ever open the dashboard remember to close the browser.

[AgainPsychoX]

Any progress?