Skip to content
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

(fix) listen.py: clear out unused code in websocket_endpoint method #3446

Closed
wants to merge 3 commits into from

Conversation

tobitege
Copy link
Collaborator

What is the problem that this fixes or functionality that this introduces? Does it fix any open issues?

Cleanup of method websocket_endpoint (listen.py) to remove unused code.


Give a summary of what the PR does, explaining any non-trivial design decisions

Variables latest_event_id and start_id are unused and can be removed.

@tobitege tobitege requested review from enyst and xingyaoww August 18, 2024 07:31
@tobitege tobitege added the backend Related to backend label Aug 18, 2024
@@ -272,12 +272,7 @@ async def websocket_endpoint(websocket: WebSocket):
session = session_manager.add_or_restart_session(sid, websocket)
await websocket.send_json({'token': token, 'status': 'ok'})

latest_event_id = -1
if websocket.query_params.get('latest_event_id'):
latest_event_id = int(websocket.query_params.get('latest_event_id'))
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is actually used? Can we double check if the latest_event_id is used in the FE?

https://github.com/OpenDevin/OpenDevin/blob/a2ea17909d1d7081d2ce677a7b94a5075e0282cb/frontend/src/services/session.ts#L63-L65

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Within that standalone method, it is just a local variable without any outside reference.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If that's the case, should we delete this from the FE too?

Copy link
Collaborator Author

@tobitege tobitege Aug 18, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Honestly, not sure what the initial intention was here.
As far as I tracked it down, it came in with #1810 in May by @rbren and it hadn't changed (much) since then.
So either this was intended to be passed on here, but idk how.
What do you think?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I see this right, this bit is trying to limit the events sent to the FE to those after latest_event_id. As far as backend is concerned, that value doesn't actually limit the session, it won't give events earlier than your session anyway. But when the session is loaded, it might be that we wanted to limit the messages sent to FE for display to the user? I had sessions with over 2k events in the stream, if we send all those to FE the poor chat box might not be too happy.

Just guessing here, I know this bit of code is in BE for a long time, but I don't remember seeing it actually limit any session yet. If this guess is remotely correct, though, we might want to implement something in FE for that?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can only remove the code from the FE 😁
If we want the FE to actually do something with that param, I'd rather have a specialist do that.

@tobitege
Copy link
Collaborator Author

@xingyaoww I need your guidance on how to proceed: remove FE references or not?
Or I could close this and open a new issue to track this for later?

@xingyaoww
Copy link
Collaborator

@tobitege i'm not super familiar with FE code though, so I'm not sure if i can give a good advice? If this is used (or will be used) in FE, i'd say we can keep it?

@rbren
Copy link
Collaborator

rbren commented Aug 20, 2024

Ah @tobitege this is actually a necessary param for when the frontend loses track of the session, and then reconnects. That way you don't have to totally refresh the page--you can just fast-forward to grab whatever events you missed while the websocket was dropped

@tobitege
Copy link
Collaborator Author

Ah @tobitege this is actually a necessary param for when the frontend loses track of the session, and then reconnects. That way you don't have to totally refresh the page--you can just fast-forward to grab whatever events you missed while the websocket was dropped

But there's the issue: the param is not actually passed into the frontend (anymore) ? 🤔

@tobitege
Copy link
Collaborator Author

Closing this: I misunderstood the basic loop intent, doh!

@tobitege tobitege closed this Aug 22, 2024
@tobitege tobitege deleted the listen-cleanup branch August 22, 2024 05:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backend Related to backend
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants