Repository navigation
[aw] SqlClient Issue Auto-Triage reported incomplete result #4704
Description
Workflow Failure
Workflow: SqlClient Issue Auto-Triage
Branch: main
Run: https://github.com/dotnet/SqlClient/actions/runs/35199990826
Warning
Task Could Not Be Completed: The agent reported that the task could not be performed due to an infrastructure or tool failure.
Reasons:
-
add_comment quota (1 per run) was consumed by an earlier test call before the real triage summary could be posted
The intended triage summary for issue Entra ID authentication broken under NativeAOT in v7.0 — Extensions.Azure reflection-based discovery is AOT-incompatible #4193 (on-demand /triage) was fully composed but could not be posted because add_comment's per-run limit of 1 was already used by a preceding diagnostic test call. Full summary content: Issue type=Bug (Regression); Environment=All required fields present; Area=Area\Netcore (NativeAOT/reflection-based auth provider discovery); Duplicates=Backport AOT-safe auth provider to release/7.0 branch #4349, NativeAOT support: get to zero warnings #1947, Improve binary size when using NativeAOT #1942, SqlClient doesn't work with Native AOT on windows #1941; Regression from v6.1.4 due to move of ActiveDirectoryAuthenticationProvider into Extensions.Azure with reflection-based discovery incompatible with NativeAOT trimming. PR Make authentication provider discovery AOT-safe #4573 is open and linked as closing this issue implementing the maintainer-endorsed fix (public SqlAuthenticationProviderManager, FeatureSwitchDefinition guard, RequiresUnreferencedCode/RequiresDynamicCode annotations). Recommended next steps: review PR Make authentication provider discovery AOT-safe #4573 against the agreed design, coordinate with Backport AOT-safe auth provider to release/7.0 branch #4349 for release/7.0 backport, add NativeAOT publish+run test coverage per NativeAOT support: get to zero warnings #1947. No label changes needed for on-demand /triage runs.
This is a structured incompletion signal (report_incomplete), not a real task outcome. Any other safe outputs emitted alongside this signal (e.g., comments) describe the failure state, not a completed review or action.
Action Required
Assign this issue to an agent to debug and fix the issue.
Debug with any coding agent
Use this prompt with any coding agent (GitHub Copilot, Claude, Gemini, etc.):
Debug the agentic workflow failure using https://raw.githubusercontent.com/github/gh-aw/main/debug.md
The failed workflow run is at https://github.com/dotnet/SqlClient/actions/runs/35199990826
Manually invoke the agent
Debug this workflow failure using your favorite Agent CLI and the agentic-workflows prompt.
- Start your agent
- Load the
agentic-workflowsskill from.github/skills/agentic-workflows/SKILL.mdor https://github.com/github/gh-aw/blob/main/.github/skills/agentic-workflows/SKILL.md - Type
debug the agentic workflow issue-triage failure in https://github.com/dotnet/SqlClient/actions/runs/35199990826
Tip
Stop reporting this workflow as a failure
To stop a workflow from creating failure issues, set report-failure-as-issue: false in its frontmatter:
safe-outputs:
report-failure-as-issue: falseGenerated from SqlClient Issue Auto-Triage · copilot · 47.6 AIC · ◷
Metadata
Metadata
Assignees
Labels
Type
Projects
- StatusShow more project fieldsIn progress
Activity
github-actions commentedon Sep 17, 2026
Agent job 35199953424 failed.
Warning
Task Could Not Be Completed: The agent reported that the task could not be performed due to an infrastructure or tool failure.
Reasons:
add_comment quota (1/run) exhausted by an accidental placeholder comment (literal '-' body) posted while debugging a shell quoting issue when building the real triage payload; the correct, fully-analyzed triage summary for issue Bogus "The target principal name is incorrect" on connecting to "." #4228 could not be posted afterward.
Analysis was completed for issue Bogus "The target principal name is incorrect" on connecting to "." #4228 (on-demand /triage). Intended summary: Issue type=Bug, Environment=All required fields provided, Area=Area\Engineering, Duplicates=None found (checked Error: The target principal name is incorrect #1621, MDS v2.0.0 | SSL Provider, error: 0 - The target principal name is incorrect #795 - different root causes), Regression=Not indicated. Root cause: reporter connects with Server=. and hits 'target principal name is incorrect' during TLS cert hostname validation; maintainer already confirmed this is by-design since '.' is not a valid DNS/SAN identity. Recommended next steps: treat as design discussion (P3), consider scoping an enhancement to normalize local aliases ('.', '(local)') to real hostname before TLS validation, and/or evaluate thumbprint-based server cert pinning as raised by the reporter; consider relabeling as Feature rather than Bug. No label changes were needed for this on-demand run (per instructions, /triage runs must not touch the Auto-Triage: Waiting for Author label). Please re-run triage or have a maintainer post this summary manually.
This is a structured incompletion signal (
report_incomplete), not a real task outcome. Any other safe outputs emitted alongside this signal (e.g., comments) describe the failure state, not a completed review or action.github-actions commentedon Sep 17, 2026
Agent job 35200108424 failed.
Warning
Task Could Not Be Completed: The agent reported that the task could not be performed due to an infrastructure or tool failure.
Reasons:
Triage summary could not be posted to issue SqlDataRecord.SetBytes fails to set length, incorrectly preserving data from a previous call #3957: the add_comment safe-output tool has a limit of 1 call per run, and an earlier test call (posting placeholder text 'test simple body' to verify tool invocation syntax) consumed that quota before the real triage summary could be sent.
Intended triage summary for issue SqlDataRecord.SetBytes fails to set length, incorrectly preserving data from a previous call #3957 (on-demand /triage run triggered by comment 5711386835):
Triage Summary
Analysis: SqlRecordBuffer.SetBytes only updates BytesLength when the internal buffer is resized, so a subsequent SetBytes call writing fewer bytes than a prior call leaves stale bytes appended to data sent to SQL Server, silently corrupting table-valued parameter data. Root cause identified in SqlRecordBuffer.cs (~L527-549). Maintainer mdaigle agreed to a plan of record: always set BytesLength after copying, not only on buffer resize. SetChars likely has the same defect. Severity: P1 (data-integrity bug with agreed fix approach; workaround via SqlBytes exists).
Next steps recommended: assign to Copilot coding agent to implement the always-set-BytesLength fix in SqlRecordBuffer.SetBytes (and audit SetChars), add regression tests for shrinking SetBytes calls, SetChars analog, and offset-based iterative SetBytes calls; note this was accidentally NOT posted due to the tool quota being exhausted by a prior test call.
Accidentally posted placeholder comment (temporary_id aw_LfKbR4Eg, body 'test simple body') should be disregarded/removed by a maintainer if visible on the issue - this was an error on my part during tool syntax verification and does not reflect the real triage conclusion.
This is a structured incompletion signal (
report_incomplete), not a real task outcome. Any other safe outputs emitted alongside this signal (e.g., comments) describe the failure state, not a completed review or action.github-actions commentedon Sep 17, 2026
Agent job 35200224735 failed.
Warning
Task Could Not Be Completed: The agent reported that the task could not be performed due to an infrastructure or tool failure.
Reasons:
add_comment quota exhausted before real triage summary could be posted
During diagnosis of a 'Permission denied and could not request permission from user' error when piping JSON via jq/python to safeoutputs add_comment (bash tool lost write/exec permission mid-session for jq and python3), I tested add_comment with a placeholder body to confirm the tool itself worked via simple --item_number/--body flags. That test call consumed the run's only add_comment allowance (limit: 1 per run), so the real triage summary for issue Revisit support for globalization invariant mode #3742 (on-demand /triage re-triage) could not be posted afterward. Analysis was completed: issue is a Feature request (globalization invariant mode support), Area\Netcore, potential duplicates Globalization Invariant Mode is not supported #220/Support Globalization Invariant Mode on alpine images #1249/Consider error diagnostic when SqlClient used when invariant globalization enabled. #2043 self-referenced by author, no regression. Please re-run the workflow to post the actual triage summary.
This is a structured incompletion signal (
report_incomplete), not a real task outcome. Any other safe outputs emitted alongside this signal (e.g., comments) describe the failure state, not a completed review or action.github-actions commentedon Sep 17, 2026
Agent job 35200302477 failed.
Warning
Task Could Not Be Completed: The agent reported that the task could not be performed due to an infrastructure or tool failure.
Reasons:
add_comment quota exhausted before real triage summary was posted
During tool troubleshooting, an accidental test call to add_comment (body: 'test comment') consumed the run's single allowed add_comment invocation before the actual triage summary for issue Consider custom xUnit test start/end logging #3701 could be posted. The full triage analysis was completed (Task/Area\Engineering classification, no duplicates found, no env validation needed since it's not a bug) but could not be delivered due to the exhausted quota. A maintainer or re-run of /triage would be needed to post the actual summary.
This is a structured incompletion signal (
report_incomplete), not a real task outcome. Any other safe outputs emitted alongside this signal (e.g., comments) describe the failure state, not a completed review or action.github-actions commentedon Sep 17, 2026
Agent job 35200148513 failed.
Warning
Task Could Not Be Completed: The agent reported that the task could not be performed due to an infrastructure or tool failure.
Reasons:
Accidentally consumed the single add_comment quota with a test/placeholder call before posting the real triage summary for issue [5.1] Flaky Test: TransientFault_IgnoreServerProvidedFailoverPartner_ShouldConnectToUserProvidedPartner #3855
During tooling verification I mistakenly invoked add_comment with a placeholder body ('-') to test stdin piping behavior, which succeeded and consumed this run's only add_comment allowance (limit 1). The intended full triage summary for the /triage on-demand request on issue [5.1] Flaky Test: TransientFault_IgnoreServerProvidedFailoverPartner_ShouldConnectToUserProvidedPartner #3855 (comment id 5711391842) was prepared but could not be posted afterward because the add_comment limit was already reached. No label changes were needed for this on-demand run per the routing rules. The prepared triage summary content: issue type Task (flaky test), area Area\Tests, potential duplicates/related issues LoginWithFailover missing parser state check causes transient errors to trigger failover instead of retry #4139, Test | SqlConnectionReliabilityTests are flaky #3821, Test | Fix flaky tests #3031, [Tests] Setup needed for Connection Pool reliability testing #3667, ChannelDbConnectionPool's async ordering test is flaky #3730, analysis of the TransientFault_IgnoreServerProvidedFailoverPartner_ShouldConnectToUserProvidedPartner flaky test showing 2 client connections instead of 1, and recommended next steps to assign Copilot coding agent to investigate the TDSServerEndPoint test harness and LoginWithFailover retry path (related to PR Fix LoginWithFailover missing parser state check #4140).
This is a structured incompletion signal (
report_incomplete), not a real task outcome. Any other safe outputs emitted alongside this signal (e.g., comments) describe the failure state, not a completed review or action.github-actions commentedon Sep 17, 2026
Agent job 35200199936 failed.
Warning
Task Could Not Be Completed: The agent reported that the task could not be performed due to an infrastructure or tool failure.
Reasons:
Posted an erroneous placeholder comment on issue Remove explicit dependency on System.Text.Json for modern .net #3766 due to a stdin-piping mistake before discovering the correct method
During on-demand /triage for issue Remove explicit dependency on System.Text.Json for modern .net #3766, an initial add_comment call used 'stdin -' for the body parameter which was not correctly interpreted, resulting in a comment with body literally '-' instead of the intended triage summary. The add_comment tool has a limit of 1 call per run, so the corrected full triage summary (issue type: Task, area: Area\Engineering, analysis of System.Text.Json dependency scoping in Microsoft.Data.SqlClient.csproj and nuspec, next steps for Copilot coding agent investigation) could not be posted. A maintainer should manually review/edit that placeholder comment or re-run /triage to get the full summary.
This is a structured incompletion signal (
report_incomplete), not a real task outcome. Any other safe outputs emitted alongside this signal (e.g., comments) describe the failure state, not a completed review or action.github-actions commentedon Sep 17, 2026
Agent job 35200482837 failed.
Warning
Task Could Not Be Completed: The agent reported that the task could not be performed due to an infrastructure or tool failure.
Reasons:
Accidental placeholder comment consumed the single add_comment quota for this run
While debugging a tool-call issue, I mistakenly called add_comment with a placeholder test string ('test comment - checking tool works') on issue Add select docs to TdsParser methods per #3555 #3584, which consumed this run's 1-comment limit before I could post the real triage summary. The intended full triage summary (issue type: Task, area: Area\Documentation, no duplicates, doc-comment follow-up to PR Merge | TdsParser functional changes #3555) was prepared but could not be posted due to the quota being exhausted. Recommend re-running /triage on issue Add select docs to TdsParser methods per #3555 #3584 to post the correct summary, and disregard the placeholder comment.
This is a structured incompletion signal (
report_incomplete), not a real task outcome. Any other safe outputs emitted alongside this signal (e.g., comments) describe the failure state, not a completed review or action.github-actions commentedon Sep 17, 2026
Agent job 35200276345 failed.
Warning
Task Could Not Be Completed: The agent reported that the task could not be performed due to an infrastructure or tool failure.
Reasons:
add_comment quota (1/run) was accidentally consumed by an earlier stdin-dash probe that posted a placeholder body ('-') instead of the intended full triage summary for issue SqlDataAdapter.Fill throws exception with the new VECTOR data type. #3723. The complete triage analysis was prepared (Issue type: Feature/enhancement per maintainer confirmation; Area: Area\Vector; Duplicates: related Vector Datatype support for SqlDataRecord #3450, Add support for vector datatype for it's usage with TVP and SqlDataRecord #3440, parent Vector Feature enhancements #3444; no regression; environment complete) but could not be posted because the add_comment limit (1 per run) was already reached by the accidental call. Recommend re-running /triage on issue SqlDataAdapter.Fill throws exception with the new VECTOR data type. #3723 to post the correct summary.
This is an on-demand /triage run on SqlDataAdapter.Fill throws exception with the new VECTOR data type. #3723 (SqlDataAdapter.Fill throws exception with the new VECTOR data type). I attempted to test stdin JSON piping for add_comment using a '-' placeholder body while debugging a sandbox permission issue with heredocs/file writes, not realizing this would count against the single-use add_comment limit for the run. That call succeeded and posted a literal '-' as the comment body (temporary_id aw_c9GoKhBt), consuming the only allowed add_comment call. The real triage summary (issue type, environment completeness, area classification Area\Vector, duplicate check against Vector Datatype support for SqlDataRecord #3450/Add support for vector datatype for it's usage with TVP and SqlDataRecord #3440/Vector Feature enhancements #3444, regression check, analysis, and next steps recommending assignment to Copilot coding agent to investigate SchemaMapping/ObjectStorage handling of SqlVector(T) for DataTable compatibility) was fully prepared but never posted. No label changes were made (correctly, since this is an on-demand /triage run). Please re-trigger /triage on this issue to get the complete summary posted.
This is a structured incompletion signal (
report_incomplete), not a real task outcome. Any other safe outputs emitted alongside this signal (e.g., comments) describe the failure state, not a completed review or action.github-actions commentedon Sep 17, 2026
Agent job 35200429529 failed.
Warning
Task Could Not Be Completed: The agent reported that the task could not be performed due to an infrastructure or tool failure.
Reasons:
Posted placeholder text 'test placeholder' instead of the full triage summary due to a tool-call quota mistake; add_comment limit (1 per run) was already consumed before the real triage summary could be posted.
On-demand /triage was requested on issue Add a separate timeout value for transaction operations such as commit #3635 (Feature: separate timeout for transaction operations like Commit). Full triage analysis was completed: Issue type=Feature, Area=Area\Connection Pooling, Duplicates=None found, Regression=Not indicated. The intended summary recommended maintainers decide between adding a new TransactionTimeout keyword vs reusing CommandTimeout, pointed to src/Microsoft.Data.SqlClient/src/Microsoft/Data/SqlClient/SqlInternalConnectionTds.cs as the unified-tree location to investigate, and suggested assigning to Copilot coding agent once a direction is chosen. Due to earlier failed attempts to build the JSON payload via jq/python (blocked by sandbox permission), a raw CLI test call using a placeholder body was made to validate argument passing, which consumed the run's only permitted add_comment call before the real summary could be sent.
This is a structured incompletion signal (
report_incomplete), not a real task outcome. Any other safe outputs emitted alongside this signal (e.g., comments) describe the failure state, not a completed review or action.github-actions commentedon Sep 17, 2026
Agent job 35200626060 failed.
Warning
Task Could Not Be Completed: The agent reported that the task could not be performed due to an infrastructure or tool failure.
Reasons:
add_comment quota (1/run) was consumed by an accidental diagnostic test call made while troubleshooting a shell command-injection guard blocking jq/python heredoc redirects; the real triage summary for issue Improve Async Pathways in Connectivity APIs #3459 could not be posted afterward.
🔍 Triage Summary (on-demand re-triage)
Area\AsyncAnalysis
This is a placeholder/tracking issue (already has 4 linked sub-issues) cataloging places where
SqlConnection.OpenAsync()and related connectivity code paths (e.g. connection resiliency reconnect, fedauth token acquisition inSqlInternalConnectionTds.cs) violate async best practices by usingTask.Runto bridge sync-over-async or async-over-sync. This affects core connectivity/async internals and can cause thread-pool starvation, deadlocks, or unnecessary blocking under load. Severity: P2 (engineering/technical-debt tracking issue, not a user-facing regression, but individual sub-issues could surface as P1 for production async deadlock/perf scenarios).Next Steps
Task.Runusage (e.g.ValidateAndReconnect'sTask.Run(() => ReconnectAsync(timeout))and the fedauthTask.Run(async () => await authProvider.AcquireTokenAsync(...)).GetAwaiter().GetResult()pattern) and propose a true async (or true sync) alternative.This is a structured incompletion signal (
report_incomplete), not a real task outcome. Any other safe outputs emitted alongside this signal (e.g., comments) describe the failure state, not a completed review or action.github-actions commentedon Sep 17, 2026
Agent job 35200807822 failed.
Warning
Task Could Not Be Completed: The agent reported that the task could not be performed due to an infrastructure or tool failure.
Reasons:
Consumed the single add_comment quota on a diagnostic test call before posting the real triage summary; the actual comment for issue SQL Connections left in CLOSE_WAIT state on Linux Azure App Service connected to SQL Server on Windows via Hybrid Connection #3174 could not be posted this run.
During tool troubleshooting (jq/python/node were all blocked by sandbox permission errors), I ran 'safeoutputs add_comment --item_number 3174 --body "test comment body"' to verify the CLI invocation worked, not realizing this run's add_comment limit is 1. That placeholder comment was recorded as #aw_MvwhwHLq, exhausting the quota before the real triage summary (Bug, Area\Managed SNI, env complete, duplicates After restart SQL Server when Shutdown error message occured connection stay in CLOSE_WAIT in alipne 3.9 docker container #155/WaitHandleDbConnectionPool: reclaimed connections never emit a soft disconnect, so activeSoftConnections drifts #4555, P2 analysis, next steps re: ManagedSni socket close path) could be submitted. Full intended comment body is preserved at /tmp/gh-aw/agent/comment.md. Recommend re-running the triage workflow for issue SQL Connections left in CLOSE_WAIT state on Linux Azure App Service connected to SQL Server on Windows via Hybrid Connection #3174, or manually posting the prepared summary.
This is a structured incompletion signal (
report_incomplete), not a real task outcome. Any other safe outputs emitted alongside this signal (e.g., comments) describe the failure state, not a completed review or action.github-actions commentedon Sep 17, 2026
Agent job 35200885088 failed.
Warning
Task Could Not Be Completed: The agent reported that the task could not be performed due to an infrastructure or tool failure.
Reasons:
Consumed the single add_comment quota with an accidental test call before posting the real triage summary for issue Frequent transport-level SqlClient exception on Linux Rocky 9.5 Minimal ISO - A transport-level error has occurred when receiving results from the server. (provider: TCP Provider, error: 35 #3052
During tooling setup I mistakenly sent a test payload ({"item_number":3052,"body":"test comment"}) to safeoutputs add_comment to verify connectivity, which succeeded and consumed this run's only allowed add_comment call (limit 1/1). The intended full triage summary for issue Frequent transport-level SqlClient exception on Linux Rocky 9.5 Minimal ISO - A transport-level error has occurred when receiving results from the server. (provider: TCP Provider, error: 35 #3052 (on-demand /triage re-triage: Bug, Area\Managed SNI, duplicates SqlException.IsTransient returns false for TCP Provider error 35 (broken pipe) — transport-level failures should be considered transient #4665 and A transport-level error has occurred when receiving results from the server. (provider: TCP Provider, error: 35 - An internal exception was caught) #2103, no version-boundary regression, recommend assigning to Copilot coding agent to investigate why MultipleActiveResultSets=True masks the TCP Provider error 35 transport reset) was prepared but could not be posted because the add_comment limit was already reached. No label changes were needed for this on-demand run. Please re-run /triage on issue Frequent transport-level SqlClient exception on Linux Rocky 9.5 Minimal ISO - A transport-level error has occurred when receiving results from the server. (provider: TCP Provider, error: 35 #3052 to have the full summary posted.
This is a structured incompletion signal (
report_incomplete), not a real task outcome. Any other safe outputs emitted alongside this signal (e.g., comments) describe the failure state, not a completed review or action.github-actions commentedon Sep 17, 2026
Agent job 35200859295 failed.
Warning
Task Could Not Be Completed: The agent reported that the task could not be performed due to an infrastructure or tool failure.
Reasons:
add_comment quota (1 per run) was accidentally consumed by an earlier test invocation that posted a placeholder '-' body instead of the real content, before the correctly-formatted triage summary could be sent.
Full triage analysis was completed for issue Microsoft.Data.SqlClient.SNI.x86.dll, version: 5.2.0.0 crashed host application #3087 (on-demand /triage request) but could not be posted: Issue type=Bug, Area=Area\Native SNI, Environment=complete, Duplicates=Unhandled native exception by SniNativeWrapper.SniOpenSyncEx / SNI_Spn::MakeSpn when opening a connection #3661 and System.DllNotFoundException: Unable to load DLL 'Microsoft.Data.SqlClient.SNI.x64.dll' In very specific scenario #1146 potentially related, Regression=not indicated. Recommended next step: assign to Copilot coding agent to investigate native SNI connection-open path thread-safety under concurrent multi-AppDomain usage. A stray comment containing only '-' was posted to issue Microsoft.Data.SqlClient.SNI.x86.dll, version: 5.2.0.0 crashed host application #3087 by mistake and should be deleted/ignored by a maintainer; a follow-up /triage run is needed to post the real summary.
This is a structured incompletion signal (
report_incomplete), not a real task outcome. Any other safe outputs emitted alongside this signal (e.g., comments) describe the failure state, not a completed review or action.github-actions commentedon Sep 17, 2026
Agent job 35201090865 failed.
Warning
Task Could Not Be Completed: The agent reported that the task could not be performed due to an infrastructure or tool failure.
Reasons:
This is a structured incompletion signal (
report_incomplete), not a real task outcome. Any other safe outputs emitted alongside this signal (e.g., comments) describe the failure state, not a completed review or action.github-actions commentedon Sep 17, 2026
Agent job 35201156210 failed.
Warning
Task Could Not Be Completed: The agent reported that the task could not be performed due to an infrastructure or tool failure.
Reasons:
Posted a placeholder/test comment on issue Synchronously opening multiple ActiveDirectoryManagedIdentity connections in parallel is very slow #2470 by mistake while debugging tool invocation syntax, which consumed the run's single add_comment allowance before the real triage summary could be posted.
The full triage analysis was completed (Bug, Area\Azure Connectivity, environment complete, potential duplicates Possible lock contention/thread pool starvation when acquiring access token causing timeout exceptions #2152/Custom AAD token provider in Winforms can still deadlock in GetFedAuthInfo #1630/SqlConnection.OpenAsync() may block on network i/o during connection creation #979/Connection gets stuck in SNITCPHandle.TryConnectParallel #2192/SqlConnection.Open raises wrongly "error occurred during the pre-login handshake" due to thread starvation #3118, no regression indicated, P2 severity — Managed Identity token acquisition contention on synchronous parallel Open() calls). The intended summary comment content is preserved below but was not posted due to the add_comment quota being exhausted by an earlier test call.
🔍 Triage Summary (on-demand re-triage)
Area\Azure ConnectivityAnalysis
When many
SqlConnection.Open()(sync) calls are issued in parallel withAuthentication=ActiveDirectoryManagedIdentityand no cached token yet exists, each connection independently races into the Managed Identity token-acquisition path instead of waiting on/reusing an in-flight token request, causing serialized/duplicated token fetches that compound with connection count and can exceedConnect Timeout.OpenAsync()does not exhibit this because its internal continuations don't block a thread pool worker while waiting on the token. This looks related to token-acquisition lock contention discussed in #2152. Likely affected component: the federated authentication/token provider path invoked from the synchronousSqlConnection.Open()/login flow (SqlInternalConnectionTds, ActiveDirectoryAuthenticationProvider / managed identity token acquisition). Severity: P2 — significant scale/perf issue under specific startup/reboot conditions with a workaround (pre-warm one connection), not a correctness bug or data loss.Next Steps
SqlConnection.Open()login path for Managed Identity/Active Directory authentication (e.g.,ActiveDirectoryAuthenticationProvider, token-acquisition caching inSqlAuthenticationProvider/SqlInternalConnectionTds) to confirm whether concurrent sync opens without a cached token each independently trigger a new token request, and whether introducing a shared in-flight-request cache/lock (similar to what likely benefits the async path) would resolve the observed serialization/slowdown without introducing deadlocks.@TomGathercole,@RobCasson) to confirm if the behavior is still reproducible on the latest SqlClient release, since this issue has been open since 5.2.0 and no version-specific fix has been tracked.This is a structured incompletion signal (
report_incomplete), not a real task outcome. Any other safe outputs emitted alongside this signal (e.g., comments) describe the failure state, not a completed review or action.github-actions commentedon Sep 17, 2026
Agent job 35201141799 failed.
Warning
Task Could Not Be Completed: The agent reported that the task could not be performed due to an infrastructure or tool failure.
Reasons:
add_comment quota (limit 1) was consumed by an earlier malformed stdin-piping attempt that posted a broken comment body ('-') to issue Additional "post-false" reads needed with non-default CommandBehavior #2472 before the real triage summary could be posted
🔍 Triage Summary (on-demand re-triage)
Area\Asyncis not applicable; best match is none of the listed labels precisely, closest is general TDS/reader behavior — recommendArea\Engineeringpending a more specific "Data Reader" area labelAnalysis
This issue concerns
SqlDataReaderbehavior withCommandBehavior.SingleResult/SingleRow: errors occurring in result sets after the first are silently discarded unless the caller callsRead()an arbitrary, query-dependent number of extra times past the point whereRead()first returnsfalse, or callsNextResult()/Dispose()— none of which reliably surfaces the trailing error whenSingleResultis specified. Maintainer@David-Engelconfirmed SqlClient drains and discards subsequent result sets/errors onNextResult()/Close()whenCommandBehavior.SingleResultis used, and agreed theRead()-after-falsebehavior is inconsistent/"incorrect" but framed it as low priority ("theoretical correctness"). The broader ask from commenters (@mgravell,@roji,@vonzshik) is that trailing SQL errors (e.g., from statements executed after the returned result set, such asSET @intvar = 'A'inside aTRY/CATCH) should be reliably surfaced viaNextResult()orDispose(), regardless ofCommandBehavior, rather than silently swallowed — a data-integrity concern (undetected failed transactions). Severity: P2 — not a crash/regression, but a "silently lost exceptions" correctness issue with real-world risk (e.g., undetected failed COMMIT/ROLLBACK, as illustrated in the repro).Next Steps
Dispose()throw, citing past regressions from that pattern, but there is rough consensus thatNextResult()and/orClose()/Dispose()should surface errors from subsequent result sets even underCommandBehavior.SingleResult.TdsParser's result-set draining path used whenCommandBehavior.SingleResult/SingleRowis set (SqlDataReader.Close()/ConsumeMetaData/TryCloseInternaland related draining logic), specifically where subsequent result-set errors are discarded instead of accumulated and re-thrown onNextResult()/Close().Read()immediately returnfalse(without silently jumping to a later result set) once a priorRead()in the same result set has returnedfalse, as flagged by multiple commenters as "theoretically incorrect" behavior.Dispose()should ever throw), any fix should be scoped carefully and likely needs a design decision/sign-off from a SqlClient maintainer before implementation, to avoid the past regressions referenced by@David-Engel.This is a structured incompletion signal (
report_incomplete), not a real task outcome. Any other safe outputs emitted alongside this signal (e.g., comments) describe the failure state, not a completed review or action.github-actions commentedon Sep 17, 2026
Agent job 35201644451 failed.
Warning
Task Could Not Be Completed: The agent reported that the task could not be performed due to an infrastructure or tool failure.
Reasons:
Accidental placeholder comment consumed the single add_comment quota before the real triage summary could be posted
During tool testing, a test call 'safeoutputs add_comment --body "test simple comment"' was executed and succeeded, posting an unintended placeholder comment to issue Consider handling error code 40613 with stretched timeout with default retry logic provider #1957. This consumed the run's only allowed add_comment call (limit 1). The intended full triage summary (Issue type: Task, Area: Connection Pooling, no duplicates found, analysis of error 40613 serverless resume retry-logic proposal) could not be posted afterward because the add_comment limit was already reached. Recommend re-running the triage workflow for issue Consider handling error code 40613 with stretched timeout with default retry logic provider #1957 to post the correct summary, and ideally deleting/editing the placeholder 'test simple comment' comment.
This is a structured incompletion signal (
report_incomplete), not a real task outcome. Any other safe outputs emitted alongside this signal (e.g., comments) describe the failure state, not a completed review or action.github-actions commentedon Sep 17, 2026
Agent job 35201546376 failed.
Warning
Task Could Not Be Completed: The agent reported that the task could not be performed due to an infrastructure or tool failure.
Reasons:
The add_comment tool was accidentally called first with a literal placeholder body ('-') instead of the intended triage summary, consuming this run's single allowed add_comment call. The correct, fully-prepared triage summary for issue The Active Directory Interactive login redirect to localhost on .net6 iOS #2062 (on-demand /triage re-triage) could not be posted as a result. The intended comment content is included in details for a maintainer to post manually or for a future run to use.
🔍 Triage Summary (on-demand re-triage)
Area\Azure ConnectivityAnalysis
The reporter is using
Authentication=ActiveDirectoryInteractiveon iOS (via a mobile app, likely Xamarin/MAUI on .NET 6), and after successfully authenticating in the embedded WebView, the browser redirects tolocalhostper the OAuth redirect URI convention but the WebView never auto-closes or hands control back to the app — leaving the user stuck with a blank/loading page and no way to proceed except manually dismissing it. This points to the interactive auth broker/WebView redirect-handling logic in the mobile SNI/auth path not detecting thelocalhostredirect as a completion signal, likely tied toMicrosoft.Identity.Client(MSAL) embedded webview integration on iOS. A minimal repro project was already provided by the author in 2023. Given interactive auth on mobile platforms is a known pain point (see related issues below) and this blocks the auth flow entirely on iOS, severity is P2.Next Steps
ActiveDirectoryInteractiveauthentication provider's WebView/redirect handling for iOS (likely in the MSAL broker integration used bySqlAuthenticationProvider/ActiveDirectoryAuthenticationProvider), specifically how thelocalhostredirect URI completion is detected and whether the WebView is expected to auto-dismiss.This is a structured incompletion signal (
report_incomplete), not a real task outcome. Any other safe outputs emitted alongside this signal (e.g., comments) describe the failure state, not a completed review or action.github-actions commentedon Sep 17, 2026
Agent job 35201866271 failed.
Warning
Task Could Not Be Completed: The agent reported that the task could not be performed due to an infrastructure or tool failure.
Reasons:
Accidentally consumed the single allowed add_comment call with a placeholder test value while debugging a shell tool issue (jq/python3 were blocked by 'Permission denied and could not request permission from user' errors), before posting the real triage summary for issue ExecuteReaderAsync hangs when Column Encryption is enabled and the worker usage of Azure DB is 100% #1762.
Triage analysis was fully completed: Issue type=Bug, Environment=All required fields provided, Area=Area\Async, Duplicates=SqlClient hangs while executing stored procedure on SQL DB with Always Encrypted #3176 and Hangs in ExecuteReaderAsync #915 potentially related, Regression=Not indicated. The intended full triage summary comment (with analysis and next-steps recommending assignment to Copilot coding agent to investigate SqlCommand.InternalExecuteReaderAsync/InternalEndExecuteReader and TdsParserStateObject.ReadAsyncCallback error propagation for Always Encrypted + MARS + fatal SqlError race) could not be posted because the add_comment safe-output limit (1 per run) was already used by an earlier placeholder test comment (body='-') that was posted while debugging blocked shell tools (jq, python3, node all returned 'Permission denied and could not request permission from user'). No label changes were made since this was an on-demand /triage run. A maintainer should manually review/delete the stray '-' comment on issue ExecuteReaderAsync hangs when Column Encryption is enabled and the worker usage of Azure DB is 100% #1762 and this workflow should be re-run to post the actual triage summary.
This is a structured incompletion signal (
report_incomplete), not a real task outcome. Any other safe outputs emitted alongside this signal (e.g., comments) describe the failure state, not a completed review or action.github-actions commentedon Sep 17, 2026
Agent job 35201982592 failed.
Warning
Task Could Not Be Completed: The agent reported that the task could not be performed due to an infrastructure or tool failure.
Reasons:
add_comment quota exhausted by an accidental placeholder test call before the real triage summary could be posted
During tool-availability testing (jq/node unavailable in sandbox), a placeholder test comment ('test placeholder - to be removed') was accidentally posted to issue Intermittent Unknown error 258 with no obvious cause #1530 via add_comment. This consumed the run's single add_comment allowance (1 per run), so the actual triage summary for the /triage on-demand request could not be posted in this run. The intended full triage summary was drafted and is available; a follow-up run is needed to post it and, ideally, to edit/delete the placeholder comment.
This is a structured incompletion signal (
report_incomplete), not a real task outcome. Any other safe outputs emitted alongside this signal (e.g., comments) describe the failure state, not a completed review or action.github-actions commentedon Sep 17, 2026
Agent job 35202049105 failed.
Warning
Task Could Not Be Completed: The agent reported that the task could not be performed due to an infrastructure or tool failure.
Reasons:
Triage summary comment was posted with placeholder content, not the real analysis
While preparing the on-demand /triage response for issue Cannot connect to (localdb) from .NET Core except via Named Pipe on Windows 11 ARM #1441, an earlier diagnostic call to add_comment (testing stdin/@- redirection support) was mistakenly executed with a literal '@-' string as the body instead of a placeholder-free test, and it consumed the single allowed add_comment call for this run before the real triage summary could be posted. The safeoutputs add_comment limit (1 per run) was then exhausted, so the intended full triage summary (Issue type: Bug; Environment: partial - missing SqlClient/LocalDB version; Area: Area\Native SNI; Duplicates: SqlException thrown related to encryption not being supported for SQL LocalDB named pipes #1395/PR Fix | SqlLocalDB instance pipename issue with Encryption #1433; Analysis of LocalDB instance-name resolution failing on Windows ARM64 due to likely native SQLUserInstance.dll architecture mismatch, with SSRP/UDP fallback also failing under managed SNI; recommended assigning Copilot coding agent to investigate SNIProxy/LocalDB native resolution logic) could not be posted. This was an on-demand /triage run triggered by a maintainer comment, so no label changes were required regardless. No other GitHub write action was taken. Recommend re-running /triage on issue Cannot connect to (localdb) from .NET Core except via Named Pipe on Windows 11 ARM #1441 to get the correct summary posted, or a maintainer can manually edit the placeholder '@-' comment on the issue.
This is a structured incompletion signal (
report_incomplete), not a real task outcome. Any other safe outputs emitted alongside this signal (e.g., comments) describe the failure state, not a completed review or action.priyankatiwari08 commentedon Sep 17, 2026
Investigation and repair update
The recorded failure for #4193 confirms the submission problem:
jqpayload preparation was denied by the workflow's shell allowlist. A diagnostictest message please ignorecall then consumed the only permittedadd_commentoperation, leaving the real summary unpublished.The repair is proposed in #4706:
jqand document checked JSON-file preparation followed by onesafeoutputs add_comment .submission. Explicitly prohibit placeholder/probe writes and-/@-stdin experiments.The content-based re-audit of all 244 original issues completed at 10:54 UTC. It preserves and verifies all 210 historical
/triagetriggers:The earlier audit incorrectly treated workflow attribution as proof of completed triage. The corrected count is 153 valid newly triggered summaries, not 185, plus 33 valid pre-existing summaries. One previously classified issue, #4691, also had only a placeholder.
There are 58 recovery candidates. Existing maintainer P0 issues #146 and #96 come first. There are 33 exact placeholder comments recorded as potential cleanup candidates, and 22
report_incompleteruns have been reconciled with this tracker. Importantly, 16 issues have valid summaries despite failed conclusion/bookkeeping jobs; those are not retry candidates. At the latest snapshot, seven runs still had pending/queued bookkeeping.The corrected execution report, priority-ordered retry list, and exact cleanup manifest are retained locally. Historical records were preserved, and the old bulk-posting/draining commands are now disabled to prevent accidental reuse.
Recovery remains paused. The repair is not deployed until it reaches the default branch. After deployment, use a small pilot and completion-gated retries, respecting the existing daily credit limit. Delete only confirmed bot placeholders after their replacement summaries are verified. Keep this tracker open until backlog recovery is complete; merging the repair PR alone is not completion of recovery.
priyankatiwari08 commentedon Sep 22, 2026
Repair tracking update: PR #4706 addresses the placeholder/comment-submission defect reported here: #4706.
It allows
jqfor JSON preparation, specifies one final-only safe-output submission, and validates the result before any comments or labels are published. Placeholder comments, unfinished summaries, and contradictory summary-plus-incomplete results are rejected. The one-comment cap and failure reporting remain enabled.The PR is still open and has not reached
main; therefore, later recurrences such as #4716 are not failures of the proposed fix.After merge, verify a small live pilot and then recover genuinely incomplete issues in budget-aware, completion-gated batches. Delete confirmed placeholders only after replacement summaries succeed. The September 17 audit's 58 recovery candidates are a historical snapshot and must be refreshed to include later failures.
Keep this tracker open until recovery is verified. #4705 concerns the separate spending guardrail and is not a defect that #4706 changes.