Cross platorm - Received id is stuck in loading state in verifier device

[santhoshsunder]

Describe the bug the received id is stuck in loading state in the verifier device

To Reproduce Prerequiste: VC is downloaded and stored in sharing device Device A - verifier device Device B - (IOS) wallet device

steps:

1. open qr code in Device A
2. open scanner in Device B
3. scan the QR code from Device B
4. Perform a sharing method
5. Click on save id button on the device A
6. and go to Received ID page

Expected behavior The VC should be downloaded, or else it shouldn't be presented at all

Actual behavior The VC is stuck in the loading state

Video : https://user-images.githubusercontent.com/102220709/222445320-716dc3b0-e35c-4510-8f12-cae0eb6f1c85.mp4

Add the screenshot of the profile page with commit id

Smartphone :

Wallet : Device B

• Phone make/model: Apple iphone 7
• OS: IOS 15.6
• BLE version : 4.2

Verifier : Device A

• Phone make/model: Redmi 7A
• OS: Android 10
• BLE version : 4.2

MOSIP Version : 1.2.0.1 MOSIP server : qa-1201-b2.net APP link : https://github.com/mosip/inji/actions/runs/4293687772 IPA Testflight version : 0.4.1 (21)

[ravikp]

The fix is given in https://github.com/mosip/inji/commit/fa142c69aaaeccc08f239060b56e0b142bef2574 to increase the DB space. This issue shouldn't happen after the db space has been increased. The video also shows the missing UIN in history page and instead shows an incremental index number. This could also be a sqlite db issue.

[ravikp]

The issue is fixed by PR - #630. Kindly test with the build that includes the mentioned PR.

[ravikp]

This issue again may come up when the stored data reaches to 30MB, which is configured in https://github.com/mosip/inji/commit/fa142c69aaaeccc08f239060b56e0b142bef2574 PR. As part of #617 enhancement, there would be an error dialog pop up comes when the data can't be stored after the VC is transfered to the verifier. So effectively it means, after #617 this behaviour shouldn't be shown.

This behaviour could also be because of how the underlying async library behaves. We request the team to test it with #630 PR.

[Raginikrishnamurthy]

@Sujithbn As per Ravi's comments, #617 #630 might have fixed the issue, as they are not assigned for testing. re assigning the bug to you.

[Sujithbn]

@Raginikrishnamurthy : #617 is a enhancement targeted for 16th MAR release which is still not released to QA team and #630 is a PR, will assign this bug along with #617 post QA handover today.

[Sujithbn]

@Anushree09-N : As discussed on triage call, Please reverify and share the inputs

[Raginikrishnamurthy]

verified as fixed in the build with commit id in the below screenshot.