-
Notifications
You must be signed in to change notification settings - Fork 347
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use new HelixAPI /job/{job}/results
endpoint
#15230
base: main
Are you sure you want to change the base?
Conversation
2ef9460
to
024f116
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wasn't able to get a repro set up to verify these changes myself. Theoretically, the code looks good to me. I added one nit.
[HelperMethod] | ||
public string MaybeCallToString(TypeReference reference) | ||
{ | ||
if (reference != TypeReference.String) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: I see this is only called in not null scenarios, but it still feels like a null check should occur in this method just in case someone else tries to consume this or someone tries to refactor the calling code and the check gets lost.
Closes #15229
Instead of relying on the SAS token returned in the new job response JSON, this PR uses the new Helix API endpoint to fetch the results URI and a short-lived SAS token for read access to the results.
To double check: