Improve Deployment Setup

[PSchmiedmayer]

Improve Deployment Setup

⚙️ Release Notes

• Improve Deployment Setup

Code of Conduct & Contributing Guidelines

By submitting creating this pull request, you agree to follow our Code of Conduct and Contributing Guidelines:

• I agree to follow the Code of Conduct and Contributing Guidelines.

[nriedman]

I went through and identified some changes that would prevent SwiftLint from throwing errors.

[PSchmiedmayer]

@nriedman We had a short Slack conversation about this PR. As you can see in the GitHub Action logs, updating some of the dependencies and fixing smaller bugs is currently causing some UI tests to fail. It would be amazing if you can take a look at the current set of tests and see why they are currently failing and fix them so we can merge the PR.

@Supereg While investigating some login issues, I have encountered that the updated Account + Firebase Module no longer reliably populates the account details in the AccountSetup { details in closure:

ENGAGE-HF-iOS/ENGAGEHF/Onboarding/AccountOnboarding.swift

Lines 21 to 26 in 9784905

	AccountSetup { details in
	if details.invitationCode != nil {
	onboardingNavigationPath.nextStep()
	} else {
	onboardingNavigationPath.append(customView: InvitationCodeView())
	}

The check above always results in the InvitationCodeView being shown despite the fact that an invitation account is attached to the user account when logging in with an existing user account. I suspect that there is a concurrent mismatch that is not waiting until the Account Storage provider returns the initial setup of user details or that they are not populated before the closure is called. I think it would make sense to continue to show the loading state until the details are loaded (and maybe show some state in the UI that the user account details are loaded).

At this point, I added the following workaround in the Invitation Code view that continuously checks if the invitation code is loaded and then proceeds with the onboarding flow:

ENGAGE-HF-iOS/ENGAGEHF/Onboarding/InvitationCodeView.swift

Lines 69 to 91 in 9784905

	.task {
	try? await Task.sleep(for: .seconds(1))
	guard account.details?.invitationCode == nil else {
	onboardingNavigationPath.removeLast()
	onboardingNavigationPath.nextStep()
	return
	}
	accountNotificationsTask = Task.detached { @MainActor in
	for await event in accountNotifications.events where event.accountDetails?.invitationCode != nil {
	guard (accountNotificationsTask?.isCancelled ?? true) == false else {
	return
	}
	onboardingNavigationPath.removeLast()
	onboardingNavigationPath.nextStep()
	accountNotificationsTask?.cancel()
	}
	}
	viewState = .idle
	}

You can replicate the issue using the local emulator. You can clone the repo and log in with one of the provided accounts by first seeding the Firebase Emulator & then running the emulator.

npm --prefix ENGAGE-HF-Firebase run prepare && firebase emulators:exec -c ./ENGAGE-HF-Firebase/firebase.json --export-on-exit=./firebase 'npm --prefix ./ENGAGE-HF-Firebase/functions run serve:seed'
firebase emulators:start -c ./ENGAGE-HF-Firebase/firebase.json --import ./firebase

If we can guarantee that the account details are loaded before the closure is called, we could remove that workaround and directly navigate to the correct screen in the next step. Let me know what you think about the issue @Supereg 🚀

[Supereg]

@PSchmiedmayer StanfordSpezi/SpeziAccount#79 fixes the issue. As described in the PR description, AccountServices did always call the storage provider "in sync" before submitting account details. However, a new requirement with SpeziAccount 2.0 is that StorageProvider must return immediately and perform the loading step asynchronously (e.g., the concept of "incomplete" account details exists). This wasn't checked for in the AccountSetup view. We added this little check and a new unit test checking that behavior.

I verified in this branch removing some of the code that this resolved the issue 👍