2 Commits

• .NET: Update Azure.AI.Projects 2.0.0-beta.1 (#4270)

  * Update Microsoft.Agents.AI.AzureAI for Azure.AI.Projects SDK 2.0.0
  
  - Bump Azure.AI.Projects to 2.0.0-alpha.20260213.1
  - Bump Azure.AI.Projects.OpenAI to 2.0.0-alpha.20260213.1
  - Bump System.ClientModel to 1.9.0 (transitive dependency)
  - Switch both GetAgent and CreateAgentVersion to protocol methods
    with MEAI user-agent policy injection via RequestOptions
  - Migrate 29 CREATE-path tests from FakeAgentClient to HttpHandlerAssert
    pattern for real HTTP pipeline testing
  - Fix StructuredOutputDefinition constructor (BinaryData -> IDictionary)
  - Fix responses endpoint path (openai/responses -> /responses)
  - Add local-packages NuGet source for pre-release nupkgs
  
  Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
  
  * Update Azure.AI.Projects to 2.0.0-beta.1 from NuGet.org
  
  - Update Azure.AI.Projects and Azure.AI.Projects.OpenAI to 2.0.0-beta.1
  - Remove local-packages NuGet source (packages now on nuget.org)
  - Fix MemorySearchTool -> MemorySearchPreviewTool rename
  - Fix RedTeams.CreateAsync ambiguous call
  - Fix CreateAgentVersion/Async signature change (BinaryData -> string)
  - Suppress AAIP001 experimental warning for WorkflowAgentDefinition
  
  Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
  
  * Move s_modelWriterOptionsWire field before methods that use it
  
  Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
  
  * Fix flaky test: prevent spurious workflow_invoke Activity on timeout wake-up
  
  The StreamingRunEventStream run loop uses a 1-second timeout on
  WaitForInputAsync. When the timeout fires before the consumer calls
  StopAsync, the loop would create a spurious workflow_invoke Activity
  even though no actual input was provided. This caused the
  WorkflowRunActivity_IsStopped_Streaming_OffThread_MultiTurnAsync test
  to intermittently fail (expecting 2 activities but finding 3).
  
  Fix: guard the loop body with a HasUnprocessedMessages check. On
  timeout wake-ups with no work, the loop waits again without creating
  an activity or changing the run status.
  
  Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
  
  * Fix epoch race condition causing unit tests to hang on net10.0 and net472
  
  The HasUnprocessedMessages guard (previous commit) correctly prevents
  spurious workflow_invoke Activity creation on timeout wake-ups, but
  exposed a latent race in the epoch-based signal filtering.
  
  The race: when the run loop processes messages quickly and calls
  Interlocked.Increment(ref _completionEpoch) before the consumer calls
  TakeEventStreamAsync, the consumer reads the already-incremented epoch
  and sets myEpoch = epoch + 1. This causes the consumer to skip the
  valid InternalHaltSignal (its epoch < myEpoch) and block forever
  waiting for a signal that will never arrive (since the guard prevents
  spurious signal generation).
  
  Fix: read _completionEpoch without +1. The +1 was originally needed to
  filter stale signals from timeout-driven spurious loop iterations, but
  those no longer exist thanks to the HasUnprocessedMessages guard.
  
  Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
  
  * Revert "Fix epoch race condition causing unit tests to hang on net10.0 and net472"
  
  This reverts commit 6ce7f01be8.
  
  * Revert "Fix flaky test: prevent spurious workflow_invoke Activity on timeout wake-up"
  
  This reverts commit 98963e17f2.
  
  * Skip hanging multi-turn declarative integration tests
  
  The ValidateMultiTurnAsync tests (ConfirmInput.yaml, RequestExternalInput.yaml)
  hang indefinitely in CI, blocking the merge queue. The hang is SDK-independent
  (reproduces with both Azure.AI.Projects 1.2.0-beta.5 and 2.0.0-beta.1) and
  is a pre-existing issue in the declarative workflow multi-turn test logic.
  
  Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
  
  * Remove unused using directive in IntegrationTest.cs
  
  Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
  
  * Restore Azure.AI.Projects 2.0.0-beta.1 version bump
  
  The merge from main accidentally reverted the package versions back to
  1.2.0-beta.5. This is the primary change of this PR.
  
  Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
  
  * Address merge conflict
  
  * Skip flaky WorkflowRunActivity_IsStopped_Streaming_OffThread_MultiTurnAsync test
  
  Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
  
  * Skip CheckSystem test cases temporarily
  
  Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
  
  ---------
  
  Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

  Roger Barreto · 2026-03-04 11:36:39 +00:00
  e7961571a8
• .NET: Fixing issue where OpenTelemetry span is never exported in .NET in-process workflow execution (#4196)

  * 1. Add reproduction test for issue #4155: workflow.run Activity never stopped in streaming OffThread path
  
  The WorkflowRunActivity_IsStopped_Streaming_OffThread test demonstrates that
  the workflow.run OpenTelemetry Activity created in StreamingRunEventStream.RunLoopAsync
  is started but never stopped when using the OffThread/Default streaming execution.
  The background run loop keeps running after event consumption completes, so the
  using Activity? declaration never disposes until explicit StopAsync() is called.
  
  Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
  
  2. Fix workflow.run Activity never stopped in streaming OffThread execution (#4155)
  
  The workflow.run OpenTelemetry Activity in StreamingRunEventStream.RunLoopAsync
  was scoped to the method lifetime via 'using'. Since the run loop only exits on
  cancellation, the Activity was never stopped/exported until explicit disposal.
  
  Fix: Remove 'using' and explicitly dispose the Activity when the workflow reaches
  Idle status (all supersteps complete). A safety-net disposal in the finally block
  handles cancellation and error paths.
  
  Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
  
  * Add root-level workflow.session activity spanning run loop lifetime\n\nImplements two-level telemetry hierarchy per PR feedback from lokitoth:\n- workflow.session: spans the entire run loop / stream lifetime\n- workflow_invoke: per input-to-halt cycle, nested within the session\n\nThis ensures the session activity stays open across multiple turns,\nwhile individual run activities are created and disposed per cycle.\n\nAlso fixes linkedSource CancellationTokenSource disposal leak in\nStreamingRunEventStream (added using declaration)."
  
  * Address Copilot review: fix Activity/CTS disposal, rename activity, add error tag\n\n1. LockstepRunEventStream: Remove 'using' from Activity in async iterator\n   and manually dispose in finally block (fixes #4155 pattern). Also dispose\n   linkedSource CTS in finally to prevent leak.\n2. Tags.cs: Add ErrorMessage (\"error.message\") tag for runtime errors,\n   distinct from BuildErrorMessage (\"build.error.message\").\n3. ActivityNames: Rename WorkflowRun from \"workflow_invoke\" to \"workflow.run\"\n   for cross-language consistency.\n4. WorkflowTelemetryContext: Fix XML doc to say \"outer/parent span\" instead\n   of \"root-level span\".\n5. ObservabilityTests: Assert WorkflowSession absence when DisableWorkflowRun\n   is true.\n6. WorkflowRunActivityStopTests: Fix streaming test race by disposing\n   StreamingRun before asserting activities are stopped.\n7. StreamingRunEventStream/LockstepRunEventStream: Use Tags.ErrorMessage\n   instead of Tags.BuildErrorMessage for runtime error events."
  
  * Review fixes: revert workflow_invoke rename, use 'using' for linkedSource, move SessionStarted earlier\n\n- Revert ActivityNames.WorkflowRun back to \"workflow_invoke\" (OTEL semantic convention contract)\n- Use 'using' declaration for linkedSource CTS in LockstepRunEventStream (no timing sensitivity)\n- Move SessionStarted event before WaitForInputAsync in StreamingRunEventStream to match Lockstep behavior"
  
  * Improve naming and comments in WorkflowRunActivityStopTests"
  
  * Prevent session Activity.Current leak in lockstep mode, add nesting test
  
  Save and restore Activity.Current in LockstepRunEventStream.Start() so the
  session activity doesn't leak into caller code via AsyncLocal. Re-establish
  Activity.Current = sessionActivity before creating the run activity in
  TakeEventStreamAsync to preserve parent-child nesting.
  
  Add test verifying app activities after RunAsync are not parented under the
  session, and that the workflow_invoke activity nests under the session."
  
  * Fix stale XML doc: WorkflowRun -> WorkflowInvoke in ObservabilityTests
  
  ---------
  
  Co-authored-by: alliscode <bentho@microsoft.com>
  Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

  Ben Thomas · 2026-02-25 19:42:45 +00:00
  425f27f989