Nick Dowmon

I definitely think we need this capability - thank you for adding this proposal! I want to expand on what you've suggested - that this capability already exists on target...

Today, we produce a table like: | Resources | Entity `_type` | Entity `_class` | | -------------------------- | -------------------- | --------------- | | AWS Account | `aws_account` | `Account` |...

OK. So maybe each row in the table links to another MD document or something?

and once it reaches ZD / vanilla / etc, it all blows up.

Should this auto-documentation _automatically_ pull any schemas from the `data-model` project? My hunch is no. We should _strongly_ encourage that developers enumerate _every_ property they're adding to this entity, even...

Interesting. According to the implementation, it should _only_ invoke the callback (publish / log an error) if `type === 'reject'`, not if `type === 'resolve'`. Maybe I messed up the...

My only question is - would making that change reduce _all_ multiple resolves to `level: 40`, or could this change be scoped to target _only_ the `node-fetch` known issue? I'd...

Great suggestion @ceelias! I think the validation inside `createIntegrationEntity` might be a good place for this. https://github.com/JupiterOne/sdk/blob/main/packages/integration-sdk-core/src/data/createIntegrationEntity.ts#L128

Good suggestion @aiwilliams. Could this be valid for both `sourceType` and `targetType`?

I'm not sure the polly recordings are the right place to put this schema validation. Those recordings will match whatever data structure the API returns, but this schema is used...