feat: add X-Client headers to datasource methods#1419
Conversation
Script size changes
Totals
|
48d576d to
abb0ba8
Compare
Added them now! It made the code much cleaner as I just put it on our |
| async getCheck(checkId: number) { | ||
| return this.fetchAPI<Check>(`${this.instanceSettings.url}/sm/check/${checkId}`); |
There was a problem hiding this comment.
I guess removing this is fine because it seems unused, I was kind of confused by it. Do we always just call listChecks then?
I refreshed individual check pages and that seems to be the case.
There was a problem hiding this comment.
Yeah, we might use it at some point and if so I'll then add it back in but right now we just get everything. There's quite a few features where we don't have a dedicated API endpoint to do something so we always revert to using the listChecks method and parse the response ourselves. (e.g. what checks are using what probes, common labels, etc.)
Closes: #1212
Problem
Customers may be managing their resources outside of the Synthetic Monitoring application but we have no way to identify what these are.
Solution
The API now accepts two headers:
X-Client-IDandX-Client-Versionwhich indicate where the interaction with the API came from. Our Terraform provider has been sending these headers for a while now and this PR adds the same headers with the Synthetic Monitoring app's values.The long-term goal here is to add a feature which identifies how resources are managed so customers can easily find the source of truth for managing them, as well as blocking interactions -- such as checks which are managed by Terraform can't be updated in the app.
Additional context
I found this ticket was a good excuse to add tests to our datasource module as I can easily see this regressing as we work on the datasource methods further.