identity_verfication request stuck in-progress due to failed /link/workflow/event request

[CorbinMontague]

Please do not include your API secret or public_key in any issue.

A detailed description of the steps to reproduce the issue

Using a link token created against the identity_verfication product, the iOS Plaid Link SDK is unable to load the start of the product workflow due to an error received from a request to https://sandbox.plaid.com/link/workflow/event fired shortly after a successful https://sandbox.plaid.com/link/workflow/start request. The identity_verfication request is then stuck in-progress and cannot be cancelled from the Plaid Dashboard.

1. Make sure a redirect URI has been setup as a Universal Link in your aasa file and registered in the Plaid Dashboard following docs here
2. Create a link_token following the docs here
3. From one of the iOS Plaid sample apps included in this repository (I used LinkDemo-SwiftUI) , use the link_token given back from the cURL request made in step 2 to create a LinkTokenConfiguration instance for calling Plaid.create().
4. Run the sample app and click on Open Plaid Link
5. Notice the view presenting Plaid's content is stuck on a white screen (see screenshot below) and an error appears in the console mentioning an invalid workflow session id:

2023-10-17 17:08:55 +0000 com.plaid.linkdemo.ios.swiftui/ ERROR: Error sending webviewFallbackOpen event: linkError(Optional(Workflow.LinkApiError(displayMessage: nil, documentationURL: nil, errorCode: Optional("INVALID_FIELD"), errorMessage: Optional("invalid workflow session id"), errorType: Optional("INVALID_REQUEST"), requestID: nil, suggestedAction: nil)), Optional("{\n  \"display_message\": null,\n  \"documentation_url\": \"https://plaid.com/docs/?ref=error#invalid-request-errors\",\n  \"error_code\": \"INVALID_FIELD\",\n  \"error_message\": \"invalid workflow session id\",\n  \"error_type\": \"INVALID_REQUEST\",\n  \"request_id\": \"WkEKaKgt6zAaW0w\",\n  \"suggested_action\": null\n}"))

6. If you perform step 4 with a proxy running, you'll notice 2 requests are fired:

A request to https://sandbox.plaid.com/link/workflow/start that successfully returns a https://verify-sandbox.plaid.com/plaid/verify/foo URL in the response which when copy/pasted into a web browser looks great, but is not rendered in-app due to the failure below.

A request to https://sandbox.plaid.com/link/workflow/event with request body:

3 {
  29: ""
}

Failing on a 400 with response body:

{
  "display_message": null,
  "documentation_url": "https://plaid.com/docs/?ref=error#invalid-request-errors",
  "error_code": "INVALID_FIELD",
  "error_message": "invalid workflow session id",
  "error_type": "INVALID_REQUEST",
  "request_id": "DBhqBNTHSPD9r1L",
  "suggested_action": null
}

What you expected to see?

I expect to see the start of the identity verification flow as defined by the template I created in the Plaid Dashboard and referenced in my create token cURL request.

Some Notes:

• The Plaid Link Android SDK does not exhibit this bug, but it also does not fire the https://sandbox.plaid.com/link/workflow/event request like the iOS SDK does. This seems to be the root of this problem since the https://sandbox.plaid.com/link/workflow/start request which is fired before the event request does not return a workflow session id in its response for the SDK to then use when calling https://sandbox.plaid.com/link/workflow/event.
• I also tested this against the 5.0.0-beta1 branch and the bug was still present.
• The auth and identity products do not exhibit this bug, but I noticed those products got a workflow session id back in the response from their calls to https://sandbox.plaid.com/link/workflow/start which they then passed along in the request body to https://sandbox.plaid.com/link/workflow/event and therefore their event requests never failed.

What you saw instead?

An error in the console:

2023-10-17 17:08:55 +0000 com.plaid.linkdemo.ios.swiftui/ ERROR: Error sending webviewFallbackOpen event: linkError(Optional(Workflow.LinkApiError(displayMessage: nil, documentationURL: nil, errorCode: Optional("INVALID_FIELD"), errorMessage: Optional("invalid workflow session id"), errorType: Optional("INVALID_REQUEST"), requestID: nil, suggestedAction: nil)), Optional("{\n  \"display_message\": null,\n  \"documentation_url\": \"https://plaid.com/docs/?ref=error#invalid-request-errors\",\n  \"error_code\": \"INVALID_FIELD\",\n  \"error_message\": \"invalid workflow session id\",\n  \"error_type\": \"INVALID_REQUEST\",\n  \"request_id\": \"WkEKaKgt6zAaW0w\",\n  \"suggested_action\": null\n}"))

The simulator stuck on a white screen and the identity verification requests stuck in-progress in the Plaid Dashboard

Screenshots that show the state of the UI (if applicable)

---

When submitting an issue for Plaid Link iOS please include the following information:

Name	Value
Link env	Sandbox
LinkKit version	4.6.5
iOS version	17.0
iOS device	iPhone 15 simulator

List of used 3rd party libraries (e.g. CocoaPods):

• Plaid

[dtroupe-plaid]

@CorbinMontague thanks for reporting. The request to https://sandbox.plaid.com/link/workflow/event shouldn't have any impact on the IDV flow. I am going to forward this to the IDV team and will report back once I have an update.

[awPlaid]

Hi @dtroupe-plaid

Corbin and the Shift Key team have a direct email thread going with Plaid. I will help troubleshoot from there and include the resolution here. Thank you!

[CorbinMontague]

As of about 30m ago this issue is suddenly no longer happening. I did not change any of my code but the IDV flow is now working as expected. From what I see in the proxy logs, the requests and responses look exactly the same as before when the IDV flow was not working, which definitely confirms the workflow/event request failure has nothing to do with the issue, but is also interesting because the workflow/start request and response look the same as when no content was being rendered before. I assume this was some kind of API/backend issue and something just got pushed to Plaid's Sandbox environment to fix this?

[awPlaid]

It was good to connect Corbin, hopefully the issue stays resolved. Let us know if you experience any more odd behavior, otherwise I will check in next week to stay up to date of your progress.Typo’d with thumbs On Oct 17, 2023, at 1:03 PM, Corbin Montague ***@***.***> wrote: As of about 30m ago this issue is suddenly no longer happening. I did not change any of my code but the IDV flow is now working as expected. From what I see in the proxy logs, the requests and responses look exactly the same as before when the IDV flow was not working, so that's interesting... I assume something must've just gotten fixed in Plaid's Sandbox environment. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>

[dtroupe-plaid]

Going to close this issue, but feel free to comment if it occurs again.

[biancafelecanwd]

Unfortunately this seems to be reproducing again for me, same scenario. POST ...workflow/event fails with 400 with the same response body and my app is stuck because I'm not handling onEvent at all. Is this a sandbox issue?

[dtroupe-plaid]

Unfortunately this seems to be reproducing again for me, same scenario. POST ...workflow/event fails with 400 with the same response body and my app is stuck because I'm not handling onEvent at all. Is this a sandbox issue?

A request to https://sandbox.plaid.com/link/workflow/event is not an onEvent event. It's something entirely different, these are internal events for Plaid's use. The failure of that event does no impact the Link flow.

[biancafelecanwd]

Got it, thanks. But how should we proceed with this issue? It seems to be happening only for the banks that have a web flow. Our redirectUri is set correctly and it worked properly last week.

Update: I've noticed that the 5.2.1 sdk version works properly, the issue seems to have been introduced in 5.3.0

[dtroupe-plaid]

@biancafelecanwd thanks for debugging this more. I've found the root case. You're correct this only occurs in 5.3.0 - this is something that can be resolved server side. I'll report back with an update ASAP.

[dtroupe-plaid]

@biancafelecanwd just following up. The issue has been identified. We will release 5.3.1 tomorrow which will resolve the issue. In the mean time you can continue using 5.2.1.