onSubmit/validate fatal errors are hidden from console / observability tooling

[jedateach]

If I provide an action like this to the HeadlessForm onError argument.

@action async onSubmit() {
  throw new Error("this doesn't bubble up")
}

I would expect the failure to bubble out of the ember app to my observability/logging tools.
However, this isn't the case.

I'm not sure if this is by design.

Ember headless forms wraps the validate and onSubmit callbacks in TrackedAsyncData from ember-async-data.

This approach makes sense for being able to present expected errors in templates.
But what about unexpected failures / bugs that you want to be seen in devTools / observability tools?

ember-async-data readme comes with this statement:

Handling errors is slightly more complicated: TrackedAsyncData “re-throws” the promises it works with when they have errors, to avoid silently swallowing them in a way that prevents you from using them with logging infrastructure or otherwise dealing with them in your app’s infrastructure. However, this means you must also account for them in your testing

This test verifies the submission failure state works:
https://github.com/CrowdStrike/ember-headless-form/blob/main/test-app/tests/integration/components/headless-form-async-test.gts#L222
...but not any bubbling out.

I'm guessing we want to have these errors bubble out.

[simonihmig]

First, this behavior is not by design. As you can see in the place that you linked to where we call onSubmit, we are not having any catch in place that would hide the rejected promise.

You are quoting ember-async-data that it “re-throws the promises", but I actually don't see that in their code. It does catch an error here, but without rethrowing. So I am not really sure what they refer to here. I think if they would rethrow, that would also change that behavior, as again we don't do any catch on our side.

What would be your expectation for the rejected errors to not be hidden? That you see them triggering a unhandledrejection event on window?

[jedateach]

Yes, the error reaching window was my expectation.
I was struggling to debug an issue, because I had no feedback. A silent failure. My use case is to perform an action beyond the form, so I hadn't wired up the isRejected check to show in the UI.

I suppose there could be valid reasons to reject the promise and present this in the form, but equally there might be unexpected bugs where that isn't suitable.

Would it be worth having a specific type of Error to throw in each circumstance? Catch all instances of FormError for presenting in ui, but throw anything else?
Probably a breaking change tough.