Error out when mfT user surpassed seat limit

[eyalb181]

Currently, unless operator:true or the user tried to use a paid feature, we fall back to OSS, which can be confusing.

[linear[bot]]

MBE-449 Error out when mfT user surpassed seat limit

[meowjesty]

For the issue in the title, we have a check in the operator that gives the user an error if they've reached the max seat count:

x mirrord exec
    ✓ running on latest (3.121.1)!
    x preparing to launch process
      ✓ layer extracted
      x checking operator
        ✓ operator version compatible
        ✓ operator license valid
        ✓ user credentials prepared
        x starting session
          x connecting to the target
Error:   × mirrord operator rejected creating a websocket connection: Maximum seat count (1) reached, session aborted
  help: If the problem refers to mirrord operator license, visit https://app.metalbear.co to manage or renew your license.

        - If you're still stuck:

This happens whether you set operator: true or if you omit the operator from mirrord.json.

I believe the only time we fallback now, is when checking license validity on the mirrord side:

https://github.com/metalbear-co/mirrord/blob/4cec84f9e9409d39155e69cc0733a3a3f87f099c/mirrord/cli/src/connection.rs#L67-L79

Where this check is just looking at date stuff:

https://github.com/metalbear-co/mirrord/blob/4cec84f9e9409d39155e69cc0733a3a3f87f099c/mirrord/operator/src/client.rs#L327-L363

One thing I'm seeing there, however, is that we're not checking the license validity on mirrord side (we're not calling the license.is_good() method which checks today against expiration_date). When implementing this stuff initially, I left it like this to prevent potential time mismatches between the user's system time, and the operator's system time (maybe the user has set their computer date to the future). Do we want to be more strict with license validity checking there? Or just avoid falling back to non-operator mirrord (give an error, instead of Ok(None))?

[eyalb181]

Not sure I understand the edge case from the user's perspective. Assuming seat limit has been surpassed and operator is set to true or omitted, when would they receive an error? When would they fall back to OSS?

[meowjesty]

I tested this scenario by changing our check in the operator here to always return the max seats reached error.

You'll get the error when we reach the "connecting to target" part, with omitted or operator: true:

https://github.com/metalbear-co/mirrord/blob/4cec84f9e9409d39155e69cc0733a3a3f87f099c/mirrord/cli/src/connection.rs#L94-L96

It should not fallback to OSS for this case.