Skip to content

Coder "app" connections are not recorded as workspace usage for the purposes of detecting idle state #11812

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
Tracked by #11503
JoshVee opened this issue Jan 24, 2024 · 9 comments
Assignees
Labels
must-do Issues that must be completed by the end of the Sprint. Or else. Only humans may set this. s1 Bugs that break core workflows. Only humans may set this. waiting-for-info The issue creator is asked to provide more information.

Comments

@JoshVee
Copy link
Contributor

JoshVee commented Jan 24, 2024

We are currently using code-server as a web app, via the coder_app resource.

It appears as though connections through this endpoint do not get recorded as workspace usage, therefore the auto-stop behaviour can still occur while in use.

@cdr-bot cdr-bot bot added the bug label Jan 24, 2024
@matifali matifali added the s1 Bugs that break core workflows. Only humans may set this. label Jan 29, 2024
@johnstcn
Copy link
Member

@JoshVee On which version of Coder are you seeing this behaviour?

@bpmct
Copy link
Member

bpmct commented Feb 15, 2024

Put in the next sprint:

  1. to reproduce
  2. to understand whether this was a regression
  3. fix this
  4. identify whether there is room for larger improvement in Coder's activity detection

@johnstcn
Copy link
Member

@bpmct is it possible that this was fixed by #11603?

@johnstcn
Copy link
Member

johnstcn commented Feb 19, 2024

I believe this should have been fixed by d583aca, which was included in 2.7.0 and later releases. Can anyone confirm if they are still seeing this behaviour?

@sreya sreya self-assigned this Feb 20, 2024
@sreya
Copy link
Collaborator

sreya commented Feb 22, 2024

Autostop is determined by the deadline of the workspace build so if we're just updating last_used_at then probably not?

@johnstcn
Copy link
Member

Given that you can override the agent stats reporting interval, I wonder if setting this to a sufficiently high value could cause this behaviour?

@stirby stirby mentioned this issue Mar 1, 2024
24 tasks
@bpmct bpmct unassigned sreya Mar 28, 2024
@bpmct bpmct added the must-do Issues that must be completed by the end of the Sprint. Or else. Only humans may set this. label Mar 28, 2024
@Emyrk
Copy link
Member

Emyrk commented Apr 9, 2024

Given that you can override the agent stats reporting interval, I wonder if setting this to a sufficiently high value could cause this behaviour?

The apps do not report metrics via the agent stats. So the agent stats reporting interval does not change this behavior.

@Emyrk
Copy link
Member

Emyrk commented Apr 12, 2024

My draft PR does fix this, but we should implement a batch sql query to handle this. The looping feels like it could be a performance hit.

EDIT: @johnstcn mentioned the connection count on the agent. See

#12916 (comment)


I think this is resolved already.

@johnstcn johnstcn added the waiting-for-info The issue creator is asked to provide more information. label Apr 15, 2024
@johnstcn johnstcn self-assigned this Apr 15, 2024
@johnstcn
Copy link
Member

I am closing out this issue for now as "cannot reproduce". Please do not hesitate to re-open it if you have more information!

In any case, we ensure this issue does not resurface when revamping activity detection (see: #12965)

@johnstcn johnstcn closed this as not planned Won't fix, can't repro, duplicate, stale Apr 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
must-do Issues that must be completed by the end of the Sprint. Or else. Only humans may set this. s1 Bugs that break core workflows. Only humans may set this. waiting-for-info The issue creator is asked to provide more information.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants