#Nyxi

1 messages · Page 1 of 1 (latest)

fast shoalBOT
rich echo
#

Hm that's weird

#

Although I haven't looked into verification session events much in the past

solid fjord
#

Normally it just fires an event for it

rich echo
#

Do you have a sample session where you got an event for the verified status

solid fjord
#

yea hold on

rich echo
#

Want to compare some things

solid fjord
#

vs_1MrOLlL7ilRdQXxE72GJF7hY

#

And this one was manually verified vs_1MkA6tL7ilRdQXxE0LLBpMPh

rich echo
#

Hm this is test mode so it's possible there's just an event delay

#

That happens sometimes but rarely

solid fjord
#

Okay

#

As long as it doesn't happen on live and there is no other underlying reason for, it's fine and I will just try again

#

(still didn't fire)

rich echo
#

Let me get another colleague to look into this async in case this is a bug

solid fjord
#

Thanks

#

We're in the final stages of testing for this so it'd be nice to get bugs out of the way

#

Probably rolling out in the next two weeks

rich echo
#

Got it. Just flagged to them

solid fjord
#

Thanks

#

Also I will excuse the photos in advance

#

Not the most flattering lighting I have going on there

mossy vortex
#

Haha I don't know if I'll have to look at the photos when looking at this but thanks for the heads up.
Have you seen this lack of event for other verification sessions or just this one so far?

solid fjord
#

Just this one as far as I remember

#

But I can't be sure

#

It's actually firing identity.verification_session.requires_input

#

instead of verified

#

so it's not just absence of event; it's the wrong one

mossy vortex
#

Interesting. From my current understanding of the logs logs I see the requires_input event being sent at 19:33 UTC but we log the actual success at 19:40 UTC.

solid fjord
#

But why does it fire requires_input at all?

#

Ah okay

#

So that's because it failed in test mode (by design)

#

and then I verified it manually at 19:40 ?

#

Which then just didn't fire the verified event as expected

#

This seems to be the only way I can simulate a success in test mode, so if there's a better way, let me know.

#

A thing worth noting is that I'm using the iOS SDK for this last one, and I used the web flow for the previous one that worked. The test mode photos are not being used when testing with the iOS SDK; it will use the photos I took instead of placeholders

#

So there's a variable at least for you

#

iOS SDK also does not let you "select outcome", it just asks for photos and fails the validation

#

I've sent this info to Megan from the Identity team also

mossy vortex
#

Interesting, would you be able to try another of each of those verification sessions? I am currently wondering if this is the test environment being backed up on events so I wonder if the web based one would send an event again and the iOS one wouldn't

solid fjord
#

I can try

#

Hold on

#

just have to reset my env

mossy vortex
#

Will also check if these are getting sent out for others in test mode.

solid fjord
#

I have such a work-from-home look today

#

So the new one on iOS SDK is: vs_1MroUWL7ilRdQXxEBmO41djm

#

It's failed and in requires_input

#

Now I will manually approve it

#

And it doesnt fire

mossy vortex
#

Thanks for checking, a colleague just found that we did generate this event for that session but it didn't get sent for some reason. Still checking in to why but this may be a one off issue

#

A two off issue

#

Checking in to that one as well. '

solid fjord
#

vs_1MroUWL7ilRdQXxEBmO41djm still requires_action

#

Do you want me to try the web flow?

rich dirge
#

Hi 👋 Pompey was having connection issues, but I was working with them on this topic so I'm taking over.

Bear with me a moment while I look at the most recent example you shared.

solid fjord
#

cool

rich dirge
#

Alright, so far it looks like this one is behaving the same as the other I was looking at. It generates .created, .processing, .requires_input Events, but then it doesn't seem to generate a .verified Event.

Taking a look to see if this behavior has been seen before, and if there is any reason it would be considered expected.

solid fjord
#

Alright

fast shoalBOT
rich dirge
#

Found a discussion that looks like it's on the same topic, reaching out to folks to confirm if it's the same.

#

Thank you for your patience. It does appear one of my teammates came across this behavior recently and has reported it to the appropriate team who is looking into correcting it.
I'll add your examples to that discussion.

Based on what I'm seeing there, this behavior appears to be isolated to manually verifying sessions (the behavior is not encountered when using the dashboard to move a session to an unverified state).

solid fjord
#

Alright, but is this only for test mode or live as well ?

#

For our use case, it’s fairly important that manual approvals work in live

rich dirge
#

I'm not seeing an indication on that, but I'd assumed manually changing sessions' states was only offered for testing purposes (though that may be a bad assumption, I don't have much experience with Identity).

solid fjord
#

You can do this on live also

#

Like manually approving ID if the system gets it wrong

#

That’s the idea anyway

rich dirge
#

Gotcha, resynced with a colleague, and based on what they're saying I do believe this behavior is impacting live mode as well, but they're actively looking into it.

solid fjord
#

Alright

#

We’re a few weeks out from deployment at the moment

#

So it’s probably fixed by then

rich dirge
#

I think if you're a few weeks out, that you're likely right and this will probably be fixed before then.

#

(but please do not interpret that as a firm commitment, just trying to give you as much information as I can)

solid fjord
#

Sure

#

I will be sure to test it out at that time and complain to my Identity contact

#

🥸

rich dirge
#

😂 haha, sounds like a plan 👍