Closed Bug 1283545 Opened 8 years ago Closed 6 years ago

Can't load an API url in firefox that uses a task cluster job_guid as a param

Categories

(Tree Management :: Treeherder: API, defect)

Product:
Tree Management
Component:
Treeherder: API
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: camd, Unassigned)

Details

The job_guids have a "/0" (or some number) at the end of them.  This is causing a proxy error if you try to load that URL in the browser on its own.  It works fine through the AJAX call, however.

The value is getting URL encoded, but still won't work on its own.  I tried adding ``encodeURIComponent(job_guid)`` in job_detail.js to ensure that the value was encoded, but doesn't seem to make a difference.

This bug was noticed while helping ekyle and discussed in bug 1283202
Here's an example of the URL that's not working:

https://treeherder.mozilla.org/api/jobdetail/?job_guid=3ddf25e9-4e48-4e71-acdd-a2fa77467a53%2F0

I think there may be a server setting that allows slashes in params?  Not sure yet.
FYI: The /0 at the end of the task ids indicate the # of the run and will be incremented by 1 for retries of the task.
Yep.  And it'd been like this for over a year from TC.  It would just be nice to figure out a way to make it work in the browser.  Helps with debugging, etc...
Or I guess we just move to job_ids everywhere? (I seem to recall us saying we might want to do that in the future, at least once the jobs are in the unified database, since guids are probably easier for the transition).
I have to admit, job guids were really great for a test I just ran.  I wanted to see if all the jobs from prod were on stage (for doing the migration to pulse from the API).  I was able to write a script that got the matching resultsets from stage and prod, then downloaded the jobs for both and compared the job_guids.  It was an easy way to see any jobs that were on prod and not on stage and vise-versa.  I couldn't have done that without the job_guids.  

I'm not saying we have to keep job_guids, but in this one case, they were very handy.

Since it came down to "types" of jobs that were showing on one vs. the other, I could have used the signatures and ensured the same signatures showed on both.  Wouldn't have been quite as accurate to pinpoint failures, but nearly so.

anyway, just a data point.  :)
Ah good point, they are handy for that :-)
Bug 1334654 should help avoid this
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.