fix: handle OPF submit payment sequence error

[Matejk00]

Closes: CXSPA-9192

[cypress]

spartacus    Run #46727

Run Properties:   Passed #46727  •  e38351f147 ℹ️: Merge e7f7111b0ef71acd78b9860e0886f8f5b67875e6 into f334ee17e07977b304f0941ea737...

Project	spartacus
Branch Review	feature/CXSPA-9192
Run status	Passed #46727
Run duration	03m 54s
Commit	e38351f147 ℹ️: Merge e7f7111b0ef71acd78b9860e0886f8f5b67875e6 into f334ee17e07977b304f0941ea737...
Committer	Mateusz Kolasa
View all properties for this run ↗︎

---

Test results
Failures	0
Flaky	4
Pending	2
Skipped	0
Passing	125
View all changes introduced in this branch ↗︎

[FollowTheFlo]

if i understand, in scenario where error is thrown from this.opfPaymentFacade.submitPayment, we return 'true' rather than catching the error?
should we create a logic that if error occurs we returns 'false'?
In GooglePayService (line 406) we have

  catchError(() => {
              return of(false);
            })

It is the logic we wrote in dociumentation
https://help.sap.com/docs/SAP_COMMERCE_CLOUD_PUBLIC_CLOUD/0996ba68e5794b8ab51db8d25d4c9f8a/1fba7ed786b44700a21435ddc07bbc98.html

opfPaymentFacade.submit({
...
}).subscribe(success=>{
    // true when order has been successful placed
});
}

[Matejk00]

Thanks @FollowTheFlo for the suggestion.

This situation arises from using the submit function as a global function, rather than invoking it within the context of a Spartacus.

Key point here isn't about error handling, but rather about managing empty emissions. If this.opfPaymentFacade.submitPayment emits no values, we want to ensure we handle such case, otherwise we are getting an error in a browser console: https://stackoverflow.com/questions/41131476/emptyerror-no-elements-in-sequence telling that emission is empty.

The last operator is designed to emit the last value from an observable sequence or a default value if the sequence is empty. By providing true as a default value, we prevent sequence errors in the console when there are no emitted values. This approach helps maintain a consistent output and avoids any unexpected behavior.

In contrast, in the catchError logic we are explicitly handling potential errors that may occur during the payment submission process. Returning of(false) to indicate failure is appropriate for error conditions. But, in my case we are not going into the error state, so that is why I can't use such proposal.

Hope it clarifies the difference. In case of additional questions please let me know :)

[FollowTheFlo]

lgtm, as discussed even though there is no catch in the pipe, partner can catch it from Promise type global function.

[FollowTheFlo]

lgtm, see comments