Remove Async handling from the core methods

[inancgumus]

This is a continuation of the efforts set in #683. Handling the Async APIs in the mapping layer. Please take a look at issue #742 for more details. This can also help the work in grafana/k6#4403—where we need to remove the promises and return errors 🤔?

Closes #742

[ka3de]

LGTM.

[ankur22]

LGTM 👍

[inancgumus]

Hey, @grafana/k6-browser, I forgot to return values from some functions and force-pushed now. Take another look if you want. No behavior change (since the methods are not implemented)—returned values are reminders for us when we want to implement these methods in the future.

[ankur22]

Guys, @grafana/k6-browser, I forgot to return values from some functions and force-pushed now. Take another look if you want. No behavior change (since the methods are not implemented)—returned values are reminders for us when we want to implement these methods in the future.

No problem. Looks even better now 😄 Could you have done a fixup instead of a force push?

[ka3de]

Guys, @grafana/k6-browser, I forgot to return values from some functions and force-pushed now. Take another look if you want. No behavior change (since the methods are not implemented)—returned values are reminders for us when we want to implement these methods in the future.

I guess adding the return types for these methods do not harm, but I wonder if it's necessary or the best to do that in this PR considering that we are now not implementing them and they will panic in any case?

Also, I personally lack a little bit of context to know if all the defined types are correct, although they look correct! But for example, in this method the returned type does not seem to match with the behavior specified in the Godoc, no?

xk6-browser/common/response.go

Lines 191 to 196 in a2bb6a2

	// Finished waits for response to finish, return error if request failed.
	func (r *Response) Finished() bool {
	// TODO: should return nil|Error
	k6ext.Panic(r.ctx, "Response.finished() has not been implemented yet")
	return false
	}

[inancgumus]

Could you have done a fixup instead of a force push?

@ankur22, yeah, TBH, I didn't want to deal with the flaky tests and put the work on you guys instead. Sorry about that :-(

[inancgumus]

@ka3de,

I guess adding the return types for these methods do not harm, but I wonder if it's necessary or the best to do that in this PR considering that we are now not implementing them and they will panic in any case?
Also, I personally lack a little bit of context to know if all the defined types are correct, although they look correct!

The PR is about returning the old behavior and this was the old behavior 🤷

But for example, in this method the returned type does not seem to match with the behavior specified in the Godoc, no?

I understand your concerns and I have the same concerns. That method was in discussions between us long before. We still don't know whether to return an error or bool. I left it as it was (bool). I could have changed the commit message, we can fix it when the time comes to implement it.