application-services Analyze logic around `connUseAfterApiClosed` error

The connUseAfterApiClosed error is declared in our swift code but may not be necessary. On the kotlin side, we let the null-pointer error bubble up instead of throwing a custom error, which may be the approach we want to take in the swift code. Ultimately we want to uniformly handle attempts to use a closed or missing connection for both consumers while also reducing the logic in our swift and kotlin wrapper code where possible. This ticket represents the work required to analyze how the places consumer code handles these connection errors and define an approach for refactoring it.

┆Issue is synchronized with this Jira Task ┆epic: Places Follow-on Work

Nov 30 '21 18:11 data-sync-user

Hey @data-sync-user is this still open to MR ?

Feb 10 '22 02:02 remote007

➤ Sammy Khamis commented:

We should wait on this until the places sqlite issue on iOS is resolved since that’ll only muddy-up the research on this https://github.com/mozilla-mobile/firefox-ios/pull/17031 ( https://github.com/mozilla-mobile/firefox-ios/pull/17031|smart-link )

Nov 08 '23 19:11 data-sync-user

Moved to bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1866512

Change performed by the Move to Bugzilla add-on.

Nov 24 '23 15:11 mhammond