- Notifications
You must be signed in to change notification settings - Fork 3
making testing better#233
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
base:main
Are you sure you want to change the base?
Conversation
RoxyFarhad commented Dec 18, 2025 • edited
Loading Uh oh!
There was an error while loading. Please reload this page.
edited
Uh oh!
There was an error while loading. Please reload this page.
socket-securitybot commented Dec 18, 2025 • edited
Loading Uh oh!
There was an error while loading. Please reload this page.
edited
Uh oh!
There was an error while loading. Please reload this page.
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
a7cd369 to bae85cdCompare53ae413 to 14a32a6Compare| break | ||
| try: | ||
| awaitasyncio.wait_for(poll_for_task_creation(), timeout=30) |
smoreinisDec 18, 2025 • edited
Loading Uh oh!
There was an error while loading. Please reload this page.
edited
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why do we wrap poll_messages in an asyncio.wait_for if poll_messages already has support for a timeout?
i can see you mentioned in the commit description that we now "break out of the loops when the expected messages have been processed" but it looks like at least in this test case we were also breaking out of the for loops when we found the expected messages before?
were we somehow polling for 30 seconds either way even if we found the task creation message?
| from .deployment_history_list_responseimportDeploymentHistoryListResponseasDeploymentHistoryListResponse | ||
| from .task_retrieve_by_name_paramsimportTaskRetrieveByNameParamsasTaskRetrieveByNameParams | ||
| from .message_list_paginated_paramsimportMessageListPaginatedParamsasMessageListPaginatedParams | ||
| from .deployment_history_list_paramsimportDeploymentHistoryListParamsasDeploymentHistoryListParams |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should this just be in main already after the config changes?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah it is weird, for some reason re-basing get rid of this diff for me ... will look into it
smoreinis left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LG, I'm still not totally clear on what the actual behavior change is when it looks like we were already breaking out of the poll_messages loop when we found the expected messages but I assume I'm missing something here about why this didn't work the way I'm reading it but approving this for now and you can help me understand this when you get a chance.
I think there's also a lint error in 050_agent_chat_guardrails in case you didn't see it.
RoxyFarhad commented Dec 22, 2025
@smoreinis reverted a lot of these changes back because you were right -> the only thing I added in some of the tests were the early breaking if the messages were all discovered which has sped up some tests |
31e2305 to b80074aCompare
The diff looks big but it isn't: