plaid
ProcessorTransactionsSyncResponse Data Verification Error
Well dang, it's definitely not supposed to do that. Thank you for the report. I've reached out to the Transactions team to let them know and will respond here once there's a further update.
Well dang, it's definitely not supposed to do that. Thank you for the report. I've reached out to the Transactions team to let them know and will respond here once there's a further update.
Thank you.
We plan to update the API behavior on the week of January 6th. (We are delaying the fix so that we can notify customers using this endpoint and give them a chance to confirm that this will not disrupt their integrations.)
We plan to update the API behavior on the week of January 6th. (We are delaying the fix so that we can notify customers using this endpoint and give them a chance to confirm that this will not disrupt their integrations.)
Thank you!
@phoenixy1 is there any new update about this?
Yes, @ovedaydin the fix should be deployed as of yesterday (we delayed it a little past the 6th because some customers were difficult to contact over the holidays). Please let us know if you're still having issues.
@phoenixy1 It seems like there are more issues here.
{'account': {'account_id': '', 'balances': {'available': None, 'current': None, 'iso_currency_code': None, 'limit': None, 'unofficial_currency_code': None}, 'mask': None, 'name': None, 'official_name': None, 'subtype': None, 'type': None}, 'added': [], 'has_more': True, 'modified': [], 'next_cursor': 'CAESJUdXUVE3WFBrTXdDN21wUnBCTDNqSUd3ZHpXa2Q2cnRHbDNvemwiDAi++L68BhCY1emjASoMCMD4vrwGEOD1sJEC', 'removed': [], 'request_id': 'tDRt2lXWhjBBwag', 'transactions_update_status': 'HISTORICAL_UPDATE_COMPLETE'}
account name can't be None account type can't be None
@ovedaydin can you share more detail about the request you're sending to get that result? I wouldn't expect it to be possible for those fields to be empty.
I believe it tries to return some data even if it's not ready. When you wait a little bit then you get the actual data. @phoenixy1 this is the code piece I use today, try catch is used to bypass type errors for now.
data = {"count": 500, "processor_token": processor_token}
if cursor:
data["cursor"] = cursor
request = ProcessorTransactionsSyncRequest(**data)
# if it fails due to data type then use last response
try:
response = client.processor_transactions_sync(request)
except Exception:
response = client.api_client.last_response.data
response = json.loads(response)
@ovedaydin sorry for the delay, it looks like I missed the notification for your response. I'll take a look at this. Is there any urgency on your side on getting this fixed? If not, I will target getting it fixed in time for the next client library release date of April 21.
@ovedaydin sorry for the delay, it looks like I missed the notification for your response. I'll take a look at this. Is there any urgency on your side on getting this fixed? If not, I will target getting it fixed in time for the next client library release date of April 21.
@phoenixy1 Thank you. As long as current implementation works by the time this gets fixed, there's no urgency. April 21 sounds good.
Hi @phoenixy1 I just wanted to check if this is going to be fixed by April 21.
@ovedaydin I believe the fix should be in the April 21 release, please let me know if the release that's going out today (might be tomorrow if there are issues with the release process) doesn't fix it.
@phoenixy1
It doesn't seem like it's fixed, I still get:
Invalid type for variable 'account'. Required value type is AccountBaseNullable and passed type was NoneType at ['received_data']['account']
I would really appreciate it if you can fix this soon or suggest something else bc doing
response = client.api_client.last_response.data is too hacky.
Oh geez, I checked and the issue appears to be this:
https://github.com/plaid/plaid-python/blob/master/plaid/model/account_base_nullable.py#L98
where nullable should obviously be true.
The root cause looks like a syntax error in the OpenAPI file, where nullable: true was added to that object at the wrong indentation level when the object was created. I've merged a fix for that and confirmed that nullable is true in the AccountBaseNullable object after rebuilding the python library.
I know this is very clowny of us, so I've asked the team if they can do an accelerated release of the python library to contain the fix.
Thank you.
{
"account": null,
"added": [],
"has_more": true,
"modified": [],
"next_cursor": "CAESJW9RNTRhcFJrUU5INXFKV1FBRE45aE14YmRicFJWYWNvSnhNNXoiDAjP8Z3BBhDw7pqJASoMCNXxncEGEIi/6f4B",
"removed": [],
"request_id": "FkVx6yMHBsjDtGc",
"transactions_update_status": "HISTORICAL_UPDATE_COMPLETE"
}
Is this expected though? How could account be null when I just picked one to create the token?
@phoenixy1 It would be helpful if you could let me know when the fix will be released.
@ovedaydin I haven't been able to reproduce a response like the one you're seeing. The only way I can get account to be null is if I call /processor/transactions/sync before the response is ready.
If you're seeing a response like that, I think something is wrong in the API and not just the client library. Can you file a support ticket?
I will let you know as soon as I have information on the date of the client library release.
PS I'm also raising the issue you're seeing with engineering, but it's best that you file a ticket to ensure that we have tracking on it.
@ovedaydin OK, the latest client library build this is now available, and it should allow null account values without an error, so I'm going to close this issue. Feel free to file a new issue if you have any other client library problems.
If you're seeing a null account in contexts when it should not be null, that's an error unrelated to the client libraries -- please file a support ticket so the Transactions team can investigate.