Skip to content

Conversation

@RoxyFarhad
Copy link
Collaborator

@RoxyFarhad RoxyFarhad commented Dec 18, 2025

The diff looks big but it isn't:

  1. the large diff comes from re-factoring the non-streaming polling to break out of the loops when the expected messages have been processed. It essentially moves the same code block into the message iterator rather than waiting for an expected time and then processing all received messages
  2. added temporal tests to the testing workflow
  3. fixed some small bugs with temporal testing

@socket-security
Copy link

socket-security bot commented Dec 18, 2025

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff Package Supply Chain
Security
Vulnerability Quality Maintenance License
Updatedagentex-sdk@​0.6.7 ⏵ 0.8.0100 +14100100100100

View full report

@RoxyFarhad RoxyFarhad force-pushed the RF/fix-test-error-handling branch from a7cd369 to bae85cd Compare December 18, 2025 13:10
@RoxyFarhad RoxyFarhad force-pushed the RF/fix-test-error-handling branch from 53ae413 to 14a32a6 Compare December 18, 2025 13:57
@RoxyFarhad RoxyFarhad requested a review from smoreinis December 18, 2025 13:57
break

try:
await asyncio.wait_for(poll_for_task_creation(), timeout=30)
Copy link
Contributor

@smoreinis smoreinis Dec 18, 2025

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_response import DeploymentHistoryListResponse as DeploymentHistoryListResponse
from .task_retrieve_by_name_params import TaskRetrieveByNameParams as TaskRetrieveByNameParams
from .message_list_paginated_params import MessageListPaginatedParams as MessageListPaginatedParams
from .deployment_history_list_params import DeploymentHistoryListParams as DeploymentHistoryListParams
Copy link
Contributor

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?

Copy link
Collaborator Author

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

Copy link
Contributor

@smoreinis smoreinis left a 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants