fix(smoke): tag builds via the request body so colon-bearing tags work - #1801
Merged
Conversation
Every child build in the first live candidate run logged:
WARNING: could not tag build #629524: ADO PUT .../tags/smoke-case%3Anoop-target
-> HTTP 400: A potentially dangerous Request.Path value was detected
from the client (:).
addBuildTags used the per-tag path form, PUT .../tags/{tag}. ADO's
ASP.NET front end validates the DECODED request path, so a ':' is
rejected even when correctly percent-encoded as %3A. Both tags this
harness writes - smoke-case:<id> and smoke-candidate:<buildId> - carry
one, so tagging failed for every case, every run.
Switches to the body form, POST .../tags with a JSON array. That
sidesteps path validation entirely, keeps the readable prefixed tag
format, and tags all of them in one request instead of N.
Verified live against build 629523: the PUT form returns 400, the POST
form succeeds and the tags appear.
Tagging is deliberately non-fatal, so this degraded silently into a
warning: every case in a lane shares one definition, and tags are how a
run is identified in that shared history, so losing them makes the lane
history unnavigable without breaking anything loudly.
Mutation-checked: restoring the PUT form fails the new test.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 323b70ff-d193-4c6e-b4c7-9ec6c3dc6ebd
|
Azure Pipelines: 2 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Every child build in the first live candidate run (629522) logged:
addBuildTagsused the per-tag path form (PUT .../tags/{tag}). ADO'sASP.NET front end validates the decoded path, so
:is rejected even whencorrectly percent-encoded as
%3A. Both tags this harness writes —smoke-case:<id>andsmoke-candidate:<buildId>— carry one, so taggingfailed for every case, every run.
Fix
Use the body form (
POST .../tagswith a JSON array). This sidesteps pathvalidation entirely, keeps the readable prefixed tag format, and tags all of
them in one request instead of N.
Verified live against build 629523:
PUT .../tags/smoke-case%3AcanaryPOST .../tagswith body["smoke-case:canary", ...]Why it degraded silently
Tagging is deliberately non-fatal. Every case in a lane shares one definition,
so tags are how a run is identified in that shared history — losing them makes
the lane history unnavigable without breaking anything loudly.
Validation
PUTform fails itnpx vitest run src/compiler-smoke-e2egreen