You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Description:
While attempting to import resources using the sentry_organization_repository resource, I encountered unclear documentation and inconsistencies in variable naming which made the process challenging. The current documentation instructs the use of the following command for importing:
From this response, it's apparent that there is no key corresponding to internal_id. Attempting to use the id for import as internal_id resulted in a warning about resource destruction due to mismatches between id and identifier. Further investigation revealed that externalSlug is effectively being used as what the import command describes as internal_id.
Issue:
The main issues are:
Lack of clarity about what constitutes internal_id in the import command.
Inconsistency in naming conventions between the documentation and what is retrieved from the Sentry API.
This has led to confusion and potential errors during the import process.
Proposed Solution:
I suggest updating the documentation to clearly define what internal_id is supposed to reference, with a direct mapping to the data obtainable through the Sentry API. A potential update could explicitly state that internal_id corresponds to the externalSlug, if that is indeed the case.
Steps to Reproduce:
Attempt to import a sentry_organization_repository using the current documentation's import command format.
Note the absence of internal_id in the Sentry API response.
Observe warnings or errors when using other IDs (such as id or externalId) as internal_id.
Expected Outcome:
The documentation should clearly map all components of the import command to retrievable data from the Sentry API, ensuring a smooth and error-free import process.
Additional Context:
Successfully completing the import using externalSlug as internal_id suggests a discrepancy between implementation and documentation. This needs to be aligned to avoid user confusion and potential data management errors.
The text was updated successfully, but these errors were encountered:
Uh oh!
There was an error while loading. Please reload this page.
Description:
While attempting to import resources using the
sentry_organization_repository
resource, I encountered unclear documentation and inconsistencies in variable naming which made the process challenging. The current documentation instructs the use of the following command for importing:However, it is unclear what
internal_id
refers to, as there is no mention of it in the data retrieved from the Sentry API.API Response Example:
From this response, it's apparent that there is no key corresponding to
internal_id
. Attempting to use theid
for import asinternal_id
resulted in a warning about resource destruction due to mismatches betweenid
andidentifier
. Further investigation revealed thatexternalSlug
is effectively being used as what the import command describes asinternal_id
.Issue:
The main issues are:
internal_id
in the import command.This has led to confusion and potential errors during the import process.
Proposed Solution:
I suggest updating the documentation to clearly define what
internal_id
is supposed to reference, with a direct mapping to the data obtainable through the Sentry API. A potential update could explicitly state thatinternal_id
corresponds to theexternalSlug
, if that is indeed the case.Steps to Reproduce:
sentry_organization_repository
using the current documentation's import command format.internal_id
in the Sentry API response.id
orexternalId
) asinternal_id
.Expected Outcome:
The documentation should clearly map all components of the import command to retrievable data from the Sentry API, ensuring a smooth and error-free import process.
Additional Context:
Successfully completing the import using
externalSlug
asinternal_id
suggests a discrepancy between implementation and documentation. This needs to be aligned to avoid user confusion and potential data management errors.The text was updated successfully, but these errors were encountered: