This test feels like it's testing too much. We could probably split it into a workspace agent test, and a coderd test.

Some notes debugging the log outputs:

In the failed test, we see bumped deadline from activity 4 times, all with connection_count:1

• 07:49:49.598
• 07:49:53.736
• 07:49:57.511
• 07:49:59.719

Generally, we only see this happen once in a unit test.

ActivityBumpWorkspace will only bump if more than 5% of the deadline elapsed.

From what I can tell:

1. The deadline was bumped at 07:49:49.598 to 08:49:49.593297. Subsequent bumps were ignored.
2. The assertion took 10s to finally detect the bump, and do the assertion. So now was now 07:49:59.891499, which was 10s late.

• This is the only spot I can see taking time: https://github.com/coder/coder/blob/9acf6acd76f1ea704d4037740b85fcca1c1fcd09/coderd/activitybump_test.go#L129-L142
• I do not see why this could block for 10s if the workspace deadline was bumped in the database.

I created this commit to add some logs which should help confirm my suspicion.
coder/coder@b0bc897

We log all API calls, so it seems the eventually loop you pointed out only runs once. It just takes ages because our CI is underpowered and we are doing to many things in parallel in that test. The API call itself returns in 1.3s according to Coderd

    t.go:99: 2024-10-15 07:49:59.841 [debu]  coderd: GET  host=localhost:39391  path=/api/v2/workspaces/22fc04a4-8aa6-42e6-954c-53c486183a95  proto=HTTP/1.1  remote_addr=127.0.0.1  start="2024-10-15T07:49:58.529362644Z"  took=1.312592225s  status_code=200  latency_ms=1312  request_id=d393a351-743c-4e06-a595-16b508e00995

So the majority of the time is just waiting for the client to actually dial up the server.

@spikecurtis good look on the api call. I was trying to verify my hunch. My added logs are a bit more explicit for next time.

That is crazy slow

Closing from coder/coder#15089

Will reopen if it flakes again