Error in $[0].cursorpos: parsing Text failed, expected String, but encountered Number

[SCLeoX]

I am using the WakaTime official vscode extension. I noticed that my extension started to error out since about 3 days ago:

My WakaTime extension log is filled with the following error message:

"caller":"/Users/runner/work/wakatime-cli/wakatime-cli/cmd/legacy/run.go:194","func":"runCmd","level":"error","message":"failed to run command: sending heartbeat(s) later due to bad request: bad request at \"https://<My domain>/api/v1/users/current/heartbeats.bulk\"","now":"2021-09-19T21:43:27-04:00","version":"v1.26.0"}

Not very helpful :/

I captured a packet that the extension is sending to my HakaTime instance, and tried to replicate it, so I can see the error message. The response was the following:

{
    "error": "BadRequest",
    "message": "Error in $[0].cursorpos: parsing Text failed, expected String, but encountered Number"
}

Once I changed the fields cursorpos and lineno to strings (wrapping them with quotation marks), the requests went through fine.

P.S. There is also a suspicious update in the WakaTime vscode extension 3 days ago adding the support for those two fields, and I suspect this has something to do with this issue..

P.P.S. I would gladly work on this issue if I can, but for the love of god I cannot understand Haskell.

[mujx]

That's a bit unfortunate, because #11 was also meant to handle this inconsistency. Seems like we need a way to handle both numbers and strings for that field.

[kammerdiener]

I am seeing this same problem with the VS Code plugin. My zsh plugin works properly but VS Code just fails.

I would also be more than happy to work on it, but having never worked with Haskell before I am probably going to cause more bugs.

[1dotd4]

Is there any spec that say which data should be sent to the server?

Looks like #16 forced everything to Text, but it's a plugin misalignment rather than a server problem. Aeson is strict when it tries to parse the JSON. Thus I guess either there's a spec that say cursorpos and lineno must be numbers or the parser should be extended to try catching both cases and casting to number (as I think you prefer having numbers over strings).

This is what I could understand by reading the code and the issues linked.

[1dotd4]

Specs exists, thus the problem is in #16.
It should be reverted to number.

[mujx]

@1dotd4 Thanks a lot for taking the time to dive into this.

Indeed the spec exists but it's not really up-to-date or followed. In reality what the upstream wakatime server allows is the actual spec. That's what I had in mind when converting Int to Text.

In order to make hakatime working again with the latest plugin version I will allow both Text and Int. In the future when all the other plugins are compliant I'll revert back to the original schema.