Summary
The IDA plugin's data-type synchronization still calls the deprecated v2 function-data-types operations, while the current SDK/API contract exposes v3 signature operations. This leaves data-type import and function-type propagation failing against the current service.
Evidence
The affected plugin paths use the generated FunctionsDataTypesApi methods for:
GET /v2/functions/data_types when importing signatures for matched functions.
GET /v2/functions/data_types and PUT /v2/analyses/{analysis_id}/functions/{function_id}/data_types while synchronizing local function changes.
The generated client bundled with the affected plugin release marks the v2 list operation as deprecated. The current Python SDK exposes the corresponding v3 contract through DataTypesApi:
GET /v3/functions/signatures
GET /v3/analyses/{analysis_id}/functions/{function_id}/signature
PUT /v3/analyses/{analysis_id}/functions/{function_id}/signature
The v3 response also changes the data model: function signatures refer to analysis-scoped data_type_id values, and the type definitions are returned in analysis-scoped groups. It is not a drop-in replacement for the old opaque data_types blob.
Impact
A valid analysis can reach the plugin with no usable function data types, and local function type edits can continue to target an obsolete endpoint. The resulting API errors are surfaced in IDA's log while the normal analysis workflow continues.
Stack-variable edits are a separate case: the current v3 signature update endpoint has no stack-variable write equivalent, so a client should not report those writes as successful until the API provides one.
Proposed direction
Migrate the plugin's read path to GET /v3/functions/signatures?function_ids=...&include_data_types=true, adapt the grouped v3 definitions to the existing IDA importer, and use the v3 signature update endpoint for function-header changes. Keep stack-variable synchronization explicitly unsupported unless a matching API operation is added.
This is an API migration issue rather than an IDA 9.3 or macOS-specific problem.
Summary
The IDA plugin's data-type synchronization still calls the deprecated v2 function-data-types operations, while the current SDK/API contract exposes v3 signature operations. This leaves data-type import and function-type propagation failing against the current service.
Evidence
The affected plugin paths use the generated
FunctionsDataTypesApimethods for:GET /v2/functions/data_typeswhen importing signatures for matched functions.GET /v2/functions/data_typesandPUT /v2/analyses/{analysis_id}/functions/{function_id}/data_typeswhile synchronizing local function changes.The generated client bundled with the affected plugin release marks the v2 list operation as deprecated. The current Python SDK exposes the corresponding v3 contract through
DataTypesApi:GET /v3/functions/signaturesGET /v3/analyses/{analysis_id}/functions/{function_id}/signaturePUT /v3/analyses/{analysis_id}/functions/{function_id}/signatureThe v3 response also changes the data model: function signatures refer to analysis-scoped
data_type_idvalues, and the type definitions are returned in analysis-scoped groups. It is not a drop-in replacement for the old opaquedata_typesblob.Impact
A valid analysis can reach the plugin with no usable function data types, and local function type edits can continue to target an obsolete endpoint. The resulting API errors are surfaced in IDA's log while the normal analysis workflow continues.
Stack-variable edits are a separate case: the current v3 signature update endpoint has no stack-variable write equivalent, so a client should not report those writes as successful until the API provides one.
Proposed direction
Migrate the plugin's read path to
GET /v3/functions/signatures?function_ids=...&include_data_types=true, adapt the grouped v3 definitions to the existing IDA importer, and use the v3 signature update endpoint for function-header changes. Keep stack-variable synchronization explicitly unsupported unless a matching API operation is added.This is an API migration issue rather than an IDA 9.3 or macOS-specific problem.