fix: prompt provision after connection init - #9679
Conversation
|
Azure Pipelines: Successfully started running 1 pipeline(s). 20 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run. |
|
Azure Pipelines: Successfully started running 1 pipeline(s). 20 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run. |
📋 Prioritization NoteThanks for the contribution! The linked issue isn't in the current milestone yet. |
There was a problem hiding this comment.
Pull request overview
Adds post-init provisioning guidance when connection services are written.
Changes:
- Counts emitted connection services and records a pending-provision reason.
- Preserves existing best-effort signal handling.
- Adds unit coverage for counting, signaling, and next-step resolution.
Reviewed changes
Copilot reviewed 7 out of 7 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
resource_services.go |
Returns the emitted connection count. |
resource_services_test.go |
Tests connection counting and skipped names. |
pending_provision.go |
Adds the connection pending reason and recorder. |
pending_provision_test.go |
Tests signal persistence and sorting. |
nextstep/resolver_test.go |
Verifies connections trigger provisioning guidance. |
init.go |
Records the reason after successful resource emission. |
init_from_code.go |
Adapts to the updated return signature. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| // models are service-hosted, and BYOM model deployments are referenced from | ||
| // azure.yaml and must already exist. | ||
| if err := emitResourceServices( | ||
| if _, err := emitResourceServices( |
There was a problem hiding this comment.
What makes this branch different, such that we don't need to potentially record connections here?
| // and wire the agent's uses: to it. A selected existing project contributes | ||
| // its endpoint so provision reuses it instead of creating a new project. | ||
| if err := emitResourceServices( | ||
| if _, err := emitResourceServices( |
There was a problem hiding this comment.
Same question as above, why is this case different?
Why this is needed
When
azd ai agent initadds a standaloneazure.ai.connection, users still need to runazd provision. Init should only record a pending connection when it actually writes the connection service. That avoids recording one when an invalid service name causes the service to be skipped.Why this approach
emitResourceServicesnow reports how many connection services it wrote. Init recordsconnectiononly when that count is greater than zero and the signal update succeeds. If updating the signal fails, init logs a warning and continues. A later init without connection input leaves existing reasons alone. Existing reason sorting and deduplication, provision-first guidance, and cleanup after successful provision are unchanged.Remote connection validation and the provisioning implementation are out of scope for this PR.
Validation
go test ./internal/cmd/...git diff --checkE2E validation
azd ai agent initwith a valid connection manifest: PASS. It wrote the connection service, addedconnectionto the pending-provision signal, and completed successfully.azd ai agent init: PASS. TheNext:section includedazd provisionandazd deploy.azd ai agent initwithout connection input: PASS. The existing pending-provision signal stayed unchanged.azd ai agent initwith a blank connection service name: PASS. It warned, skipped the connection, and did not addconnectionto the signal.azd ai agent initusing local code: PASS. The from-code path completed through the shared resource-service code.Closes: #9685