Ensuring initialize has returned before attempting queries.

[project-saf]

Very infrequently, I run in to a crash along the lines of:

ParseSwift/Parse.swift:106: Fatal error: Unexpectedly found nil while unwrapping an Optional value

Here is my AppDelegate:

@main
class AppDelegate: UIResponder, UIApplicationDelegate {

    func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
        Task {
            guard let AppID = Secrets.App_ID,
              let ClientKey = Secrets.Cli_ID,
              let AppURL, let LiveURL
            else { fatalError("Incorrect implementation of Secrets") }
            let config = ParseConfiguration(AppID, ClientKey, AppURL, LiveURL)
            try await initialize(configuration: config)
        }
        return true
    }

}

I was hesitant to report it since I can't reproduce it consistently, but I thought I'd flag it anyway just in case you:
(a) wanted to know, and/or
(b) had any insight as to what might be causing the issue.
It definitely does crash with the same error if I comment out the Task in didFinishLaunching and then run a query.
My guess therefore is that it is some sort of issue with the login task being de-prioritised over some other Parse function like a query.

Line 106 is the following:

l104    /// The current `ParseConfiguration` for the ParseSwift client.
l105    public var configuration: ParseConfiguration {
l106        Parse.configuration
l107    }

Questions

1. Is my AppDelegate code the intended way for Parse to be initialised?
2. Is there a way to guarantee the login task completes either before returning from didFinishLaunching, or at least completes first before any other Tasks?
3. Is it wise/possible to 'bake' into ParseSwift a means of ensuring that a query won't run until after the initialize function has completed? For example, a flag that makes those other tasks continue waiting until after initialize has returned.

[cbaker6]

Can you post the code for how your app attempts to make its first Swift call (this can be a login, query, or parse installation call)? If you climb up the debug stack when the error occurs, you should be able to find the exact line causing the problem.

To reproduce the error consistently, add a delay of ~5 seconds right before try await initialize(configuration: config)

1. Is my AppDelegate code the intended way for Parse to be initialised?
2. Is there a way to guarantee the login task completes either before returning from didFinishLaunching, or at least completes first before any other Tasks?
3. Is it wise/possible to 'bake' into ParseSwift a means of ensuring that a query won't run until after the initialize function has completed? For example, a flag that makes those other tasks continue waiting until after initialize has returned.

See thread #37 (reply in thread)

[project-saf]

To reproduce the error consistently, add a delay of ~5 seconds right before try await initialize(configuration: config)

I can confirm that adding in the delay consistently reproduces the error.

Can you post the code for how your app attempts to make its first Swift call (this can be a login, query, or parse installation call)?

So once didFinishLaunching runs, it launches my (simplified) HomeVC:

class HomeVC: UIViewController {
    
    override func viewDidLoad() {
        super.viewDidLoad()
        Task {
            do { try await fetch() }
            catch { print(error) }
        }
    }
    func fetch() async throws {
        let staff = Staff(objectId: "someObjectID")
        let slip = try await Payslip.query("staff_" == staff).first()
    }

}

See thread #37 (reply in thread)

The thread seems to suggest that this issue doesn't exist after v5.0.1 but I'm running v5.9.2
It definitely helped with me understanding if my code was correct, and ways to help it return before other tasks (or in lieu of that, put up a flag), so appreciate you pointing me in that direction 😊

[cbaker6]

The thread answers your questions about if the SDK can wait to initialization, which it’s designed to do though there can always be bugs. Can you show the full stack error since you can replicate the issue?

Also, can you try branch #168 to see if the problem still exists?

In addition, can you comment out the “fetch” function call in your viewDidLoad and report back if the crash still occurs

[project-saf]

I'm not 100% sure what you want to see when you say "the full stack error", I'm assuming it's the left panel in the screenshot below, but let me know if you meant something else.

Commenting out the fetch does not result in a crash.

Will try #168 shortly!

[cbaker6]

Using the same type of screenshots. In the left panel, you are currently on “6”, can you click on “7”, “8”, and “9” and show the screenshots for each?

Uncomment the lines I mentioned before when capturing the screenshots

[cbaker6]

PR 168 won't fix your crash. To address your issue, you will have to make a change to your code to prevent the crash as the fix that needs to be made is a breaking change to the SDK. You need to do the following:

func fetch() async throws {
        // Insert these lines to delay for 1 second, if you still see an issue, increase the delay
        let nanoSeconds = UInt64(1 * 1_000_000_000)
        try await Task.sleep(nanoseconds: nanoSeconds)

        let staff = Staff(objectId: "someObjectID")
        let slip = try await Payslip.query("staff_" == staff).first()
}

The problem is you are using the old appDelegate lifecycle and your viewDidLoad is being called before the Swift SDK finishes initialization. In addition, your specific query let slip = try await Payslip.query("staff_" == staff).first() requires the configuration to be finished which is why you are seeing the random crash. You can either add the lines above or switch to the SwiftUI lifecycle to prevent your crash (an example of using ParseSwift with the appDelegate and the new SwiftUI lifecycle can be found at https://github.com/netreconlab/CareKitSample-ParseCareKit). For further details on the appDelegate you are using see #37 (reply in thread)

If you modify your QueryConstraint's to not use any constraint that contains the comments you shouldn't see your crash.