I tried to add category and notes support to the existing time-tracking commands:
hey timetrack categories
hey timetrack start --category "Dev Work"
hey timetrack stop --category "Dev Work" --notes "Worked on the CLI"
Listing categories works through TimeTracks().Categories(), and saving notes while stopping a timer also works.
However, testing the implementation against the real HEY service exposed two problems with the current SDK contract.
Assigning a category after starting stops the timer
Because TimeTracks().Start() does not accept metadata, I tried the sequence suggested by the SDK:
- Call
TimeTracks().Start()
- Call
TimeTracks().Update() with the category
The CLI reported that tracking started, but there was no ongoing timer afterward:
$ hey timetrack start --category "Dev Work"
Time tracking started.
$ hey timetrack current
No active time track.
HEY created a zero-duration entry whose starts_at and ends_at were identical. This also happened with a category returned by TimeTracks().Categories(), so it was not caused by an invalid category.
Category is ignored when stopping
Starting without a category works:
$ hey timetrack start
Time tracking started.
$ hey timetrack current
Active time track #171250255
Stopping with both category and notes also returns success:
$ hey timetrack stop --category "Dev Work" --notes "Does it work?"
Time tracking stopped.
However, HEY saved the notes while leaving the entry uncategorized.
The SDK's update payload currently sends:
{
"calendar_time_track": {
"category": "Dev Work",
"notes": "Does it work?",
"ends_at": "..."
}
}Completed time-track creation uses category_title instead. The production behavior suggests that the update payload's category field does not match what the server expects.
Conclusion
The CLI implementation is currently blocked because the SDK does not appear to support assigning a category reliably:
- Updating an ongoing timer completes it immediately.
- Updating a timer with
category does not persist the category.
- Notes and category discovery work correctly.
The SDK/server contract needs to be confirmed and corrected before category flags can safely be added to hey timetrack start and hey timetrack stop.
Maybe I should have filed this in the SDK, I was not sure.
I tried to add category and notes support to the existing time-tracking commands:
Listing categories works through
TimeTracks().Categories(), and saving notes while stopping a timer also works.However, testing the implementation against the real HEY service exposed two problems with the current SDK contract.
Assigning a category after starting stops the timer
Because
TimeTracks().Start()does not accept metadata, I tried the sequence suggested by the SDK:TimeTracks().Start()TimeTracks().Update()with the categoryThe CLI reported that tracking started, but there was no ongoing timer afterward:
HEY created a zero-duration entry whose
starts_atandends_atwere identical. This also happened with a category returned byTimeTracks().Categories(), so it was not caused by an invalid category.Category is ignored when stopping
Starting without a category works:
Stopping with both category and notes also returns success:
However, HEY saved the notes while leaving the entry uncategorized.
The SDK's update payload currently sends:
{ "calendar_time_track": { "category": "Dev Work", "notes": "Does it work?", "ends_at": "..." } }Completed time-track creation uses
category_titleinstead. The production behavior suggests that the update payload's category field does not match what the server expects.Conclusion
The CLI implementation is currently blocked because the SDK does not appear to support assigning a category reliably:
categorydoes not persist the category.The SDK/server contract needs to be confirmed and corrected before category flags can safely be added to
hey timetrack startandhey timetrack stop.Maybe I should have filed this in the SDK, I was not sure.