I think this behaviour is as expected, see

If the goal here is to extend the workspace autostop time, an alternative would be to use the putWorkspaceTTL endpoint directly, which is the endpoint that gets hit when you click the [+] button in the UI. Example:

curl -XPUT 'https://coder.example.com/api/v2/workspaces/{workspace_id}/extend' -H "Coder-Session-Token: $(cat ~/.config/coderv2/session)" --data-raw "{\"deadline\":\"$(date --utc -d '+1 hour' +%Y-%m-%dT%H:%M:%SZ)\"}"

Note that this endpoint requires a session token and not just an agent token.

It's very desirable for the agent token to be able to bump the activity so that user login is not required to accomplish this, as actual usage is in a crontab.

Could the report-stats endpoint accept the PATCH method and then would mean only update the keys defined in the body? So that connections_by_proto: {"ssh": 1} would leave the other connections untouched?

@mattlqx You don't need a human to interact with the workspace in order for that to work.

You can retrieve a valid session token for the workspace owner using data.coder_workspace.XXX.owner_session_token (link). Similarly, if you need the workspace ID, this is accessible via data.coder_workspace.XXX.id.

Does that address your use case?

That helps, I'll give it a shot.

/api/v2/workspaces/{workspace_id}/extend could work but would require multiple API calls to get the current stop time to not set the value lower than what is already set. It also doesn't help track activity to get that Last Used display to be more accurate.

It would be much better if report-stats could accept partial updates.

@mattlqx Thanks, that's good feedback. We do have some plans to rework how our workspace scheduling (see: #11503)

I'm not sure if this is the right place to post, but I wanted to add it here.

We also need similar functionality for dynamically extending the workspace runtime during use. We have scenarios like:

1. Direct external connections to the workspace, without using Tailscale.
2. Running processes (by name).
3. High CPU load.
   It would be great if these could be taken into account.

Would the ability to specify a positive delta to /extend cover this use case?

e.g.

curl -XPUT 'https://coder.example.com/api/v2/workspaces/{workspace_id}/extend' \ 
  -H "Coder-Session-Token: $(cat ~/.config/coderv2/session)" \
  --data-raw "{\"delta\":\"1h23m45s"}"

I believe a simple endpoint that updates variable like last_human_used_at would be beneficial. Then, connect the shutdown timing to last_human_used_at.

It seems that basing shutdowns on user connections was not the best approach (PR).

Just here to say that I too would like the ability to update the last_used_at timestamp using the Agent Token. My use case is that I have been using Coder to spin up GUI-based VMs, which use external coder_apps. The method in the docs shown in the original post would be ideal, but I can also confirm it doesn't work.

The following curl works to update the token, but it's suboptimal for the reasons listed above. I'm going to use it for now, but I'd love to have a proper way to do this.

curl -X POST "${CODER_URL}/api/v2/workspaceagents/me/report-stats" -H "Coder-Session-Token: ${CODER_AGENT_TOKEN}" -d '{"connections_by_proto":{"ssh":1},"session_count_ssh":1}'

#12659 introduces an API endpoint POST /api/v2/workspaces/{workspace_id}/usage which allows directly updating the last_used_at timestamp of a workspace. It's been merged to main and should end up in the next release cycle.

Edit on Sep 9 2024: As of Coder v2.13.0, the /usage endpoint does not prevent the workspace from being automatically stopped unless the workspace-usage experiment is enabled. This experimental behaviour will become the default in a future release. If you wish to prevent a given workspace from being automatically stopped, please use the /extend endpoint to update the deadline for the given workspace. The coder schedule override-stop command can also be used to accomplish this.

The above was included in v2.10.0.