When getting the value of RENDER_INSTANCE_ID from code we get this:
But when looking at this job in Render’s UI we see a shorter string:
you can see the difference in the last part:
Shouldn’t RENDER_INSTANCE_ID contain the value that is shown in the UI?
That’s a great question, this actually applies to all primitives on us, whether it be a service, a database, a cron, a job etc. In this case it’s probably less relevant to jobs though as each run is unique.
The shorter form is the identifier of the primitive, in this case the job - the random string appended to the end is to ensure there aren’t naming conflicts when running multiple instances, particularly relevant for services and background workers more so. If you were to scale a webservice to multiple instances the srv-id would remain the same for all of the instances but there would a different random string at the end of all the instance-ids.
In this case, if you’ve coded the tagging of the Sentry event you could trim the last part so it matches but the two in this case are the same thing.
“In this case it’s probably less relevant to jobs though as each run is unique …”
Maybe I am missing something (-: but I think the exact opposite is true: JOBS are specifically interesting because each job is unique.
Now we are starting to use Render jobs in a data engineering/flows environment.
We need a consistent identifier. This identifier should be the same when looking at it from the UI and taking it from the code.
To give more context, let’s say I am a data engineer and I am writing some flow using a Render job. Inside the job’s code, we want to send out events/data to other systems (Datadog for logging for example). So we also want to send the unique id of the job.
That way, if the job fails, and we look at it in Render’s dashboard, we can quickly copy the id shown and search it in those other systems.
Omitting that last part of the id might seem harmful but in a complex system, the last thing you want is inconsistent identifiers, especially for something ephemeral as a render JOB.
I really think this should be prioritized
You can omit the last part, for a job the RENDER_INSTANCE_ID is only valid for the single execution of the job, even with the random string removed it will be uniqie. The id is returned when the job is created via our API, there cannot be duplicates and there cannot be multiple instances of a job so it’s safe to trim the random string off the end if you’re looking for a way to identify the job in code.
I think we should also consider adding it to the docs regarding jobs.
It’s a small gotcha but I think it’s important.
Something like “In Render jobs, trimming the last part of RENDER_INSTANCE_ID will still result a unique identifier…”