[bug] [plugin-nfc] NFC Write on iOS can't be used after an NFC prompt is cancelled

[zaphim12]

Describe the bug

On iOS, when an NFC write is initiated, there is a native Apple prompt that appears saying "Ready to Scan". Writing works fine when this prompt is open. However, if the prompt is closed or cancelled before a card is scanned, then future NFC writes will instantaneously fail with the error: "connected tag not found, please wait for it to be available and then call write()" - which comes from this line in the NFC plugin.

This error triggers when a session is open but either session.nfcSession, session.tagStatus, or session.tag evaluates to 'nil'. As far as I can tell, the only way to remedy this currently is to reload the app or to complete a successful NFC read operation to close the session.

Reproduction

I have tested this by creating a brand new tauri project and just implementing a button which triggers NFC writes. Here's the relevant code from my App.tsx

async function doNfcWrite() {
  try {
    const payload = [textRecord("12345")];

    const options = {
      kind: {
        type: "ndef" as const,
      },
      message: 'Scan a NFC tag',
      successfulReadMessage: 'NFC tag successfully scanned',
      successMessage: 'NFC tag successfully written',
    };
    await write(payload, options);
  } catch (e) {
    console.error(e);
  }
}

Expected Behavior

The NFC write should be usable even if a prompt was cancelled one time

Additional Context

I can think of two easy fixes for this. One is to modify the if/else mentioned above to close the session in the case that a session is open with no tag, nfcSession, or tagStatus available. The other is to enable the user to manually close a session in cases like these by exposing another plugin command which just closes the current session. I'm happy to implement the fix for this if that is acceptable.
EDIT ---
Actually on further inspection I see a better fix. When the scan is cancelled, an error is already caught and printed here on line 201. I believe that in this case it is best to add a call to 'closeSession()'. This will ensure future writes aren't blocked by a invalid session remaining.

[FabianLars]

EDIT ---
Actually on further inspection I see a better fix. When the scan is cancelled, an error is already caught and printed here on line 201. I believe that in this case it is best to add a call to 'closeSession()'. This will ensure future writes aren't blocked by a invalid session remaining.

Sounds like a good first approach at least. Either way i'd prefer a solution that would not require the dev to close the orphaned session manually.

[zaphim12]

Thanks for the quick response. Agreed that a manual approach is not ideal.
I've tested this change to call closeSession() in these error cases, and it fixes the issue in my test project. Please have a look at the PR whenever you have time.
#2885