Saving a pipeline search fails silently for legacy visualstudio.com URLs (AzureUri.IsDefinition rejects non-dev.azure.com host)

Summary

Saving a pipeline search fails silently when the pipeline URL uses the legacy *.visualstudio.com host format. The equivalent dev.azure.com URL works. The UI gives no clear error, so it looks like the save succeeded when nothing was persisted.

Impact — silent failure with a misleading "success" ⚠️

This currently fails silently: the UI looks like the save succeeded, but it saves nothing. After clicking Save pipeline, the command bar shows a generic "Successful" indication, the form closes as if it worked, yet:

• the pipeline does not appear in the Saved Pipeline Searches list, and
• nothing is written to the datastore (the DefinitionSearch table stays empty).

Because there is no visible error, the user reasonably believes the save worked and only later notices the entry was never created. This misleading feedback is arguably worse than the validation restriction itself.

Repro

1. Command Palette → Azure Extension → Saved Pipeline Searches → Add pipeline.
2. Enter a legacy-host pipeline URL, e.g. https://microsoft.visualstudio.com/Dart/_build?definitionId=76541, give it a name, and click Save pipeline.
3. The command bar shows a generic "Successful", but the pipeline is not added to the list and nothing is written to the datastore.

Using the dev.azure.com form of the same pipeline saves correctly:
https://dev.azure.com/microsoft/Dart/_build?definitionId=76541

Root cause

AzureUri.IsDefinition requires the host to be exactly dev.azure.com:

// AzureExtension/Client/AzureUri.cs — InitializeIsDefinition()
if (!Uri.Host.Equals("dev.azure.com", StringComparison.OrdinalIgnoreCase))
{
    return false;
}

For a legacy *.visualstudio.com URL, IsValid is true but IsDefinition returns false, so AzureClientHelpers.GetInfo returns InvalidDefinitionUri and SaveSearchForm.SubmitForm rejects the save before persisting anything.

The reason the failure is silent (looks successful): on validation failure SaveSearchForm.SubmitForm returns CommandResult.KeepOpen() — a normal result — so the Command Palette host still shows its generic "Successful" instead of an error.

This is inconsistent with the query and repository validators (IsQuery, IsRepository, IsTempQuery), which do not restrict the host and therefore accept both dev.azure.com and legacy *.visualstudio.com formats. There is also an existing unit test that intentionally asserts the legacy host is rejected for definitions (AzureUri_IsDefinition_Validation), so this is current-by-design behavior rather than an accidental regression.

Empirically confirmed:

Suggested fix

1. Allow legacy *.visualstudio.com hosts in AzureUri.IsDefinition, consistent with IsQuery/IsRepository (host validity is already enforced by IsValid). Practically, this means removing the dev.azure.com-only host check in InitializeIsDefinition() and updating the AzureUri_IsDefinition_Validation unit test to expect the legacy host to be accepted.
2. Fix the silent failure: surface a clear inline/error message when a save is rejected by validation, so the user is not shown a generic "Successful" after nothing was saved.

Notes

• Not caused by the .NET 10 migration — this is pre-existing behavior in AzureUri.
• A candidate change for (1) was prototyped and reverted to keep the .NET 10 PR scoped to the version update; filing this to track the fix on its own merits.

Start with AzureExtension/Client/AzureUri.cs and InitializeIsDefinition(), then inspect the AzureUri_IsDefinition_Validation unit test. Trace AzureClientHelpers.GetInfo and SaveSearchForm.SubmitForm to understand the rejected-save path. Done means legacy visualstudio.com definitions are handled consistently with other Azure URLs and rejected saves show a clear error instead of a generic success.