Feat: extra validations for browser checks

[VikaCep]

To prevent execution errors, we're adding some extra validations, in particular, these properties are not allowed in the options object:

• duration
• vus > 1
• iterations > 1

[w1kman]

When entering values as one "should", validation works.
But it's also very easy to bypass the validation.

(Note: when valid values are used in the same way, the test passes)

IMO, duration, vus and iterations should be stripped before running the script (if they aren't already).
If anything, we should notify the users that the mentioned properties doesn't have any effect 🤷🏻

[ckbedwell]

But it's also very easy to bypass the validation.

@VikaCep this comes back to what we discussing yesterday and could explore further if we could modify the k6 types that we pass to Monaco.

[VikaCep]

I enforced the validation to ensure that iterations and vus can only be either undefined or 1, addressing the potential bypass issue identified by Thomas.

Specifically, what I'd prefer to avoid is rejecting a script with {vus: 1, iterations: 1}, as those are perfectly valid.

We don't want to reject scripts with configurations like the one above, as Nadia pointed out. That's the reason I don't mark it as invalid when these properties are defined.

IMO, duration, vus and iterations should be stripped before running the script (if they aren't already).
If anything, we should notify the users that the mentioned properties doesn't have any effect 🤷🏻

I think that’s a valid point, but it might confuse some users who may not understand why those configurations aren’t taking effect, especially when copy/pasting scripts between k6 and SM. However, with clear messaging, we could mitigate that confusion. Personally, I believe marking it as a validation error is a good way to teach users that those values are not valid for a synthetic monitoring check and should not be wrongly set.

@VikaCep this comes back to what we discussing yesterday and could explore further if we could modify the k6 types that we pass to Monaco.

I agree—this is a great idea since it’s easy to expand and add new rules. We should investigate this further; I’m not sure how we can implement it yet, but it’s definitely worth exploring in a follow-up PR.

[peterschretlen]

👍 this seems like a good 80/20 solution for the time being. Does seem like there's followup work we can do to tighten loopholes on both the frontend and backend.

[w1kman]

LGTM! 👍🏻