Why is my Either-returning method always returning Left, irrespective of what happened?

[MrYossu]

The use case here is that I have added a method to an Entity Framework DbContext that does some extra work before saving, and then returns an Either depending on the results. A very simplified version of this looks like this...

static async Task<Either<string, Unit>> SaveChangesAsyncEither(string userId) {
  // In reality, this would do some auditing, check for concurrency issues, and
  // attempt to save the changes. It would return unit if all went OK, 
  // or an error message if not. Simple check for demonstrating the issue...
  if (userId == "jim") {
    return "We don't like Jim";
  }
  return unit;
}

This method is used in many places in my solution, and wors fine.

In one minimal API project, I have a method that looks like this (again, highly simplified)...

static async Task<Either<DeviceApiResponseStates, DeviceApiResponseStates>> CreateDevice(string userId) {
  // In reality we would have more parameters, create a device, etc before
  // calling SaveChangesAsyncEither
  return (await SaveChangesAsyncEither(userId))
      .Match(() => Right<DeviceApiResponseStates, DeviceApiResponseStates>(DeviceApiResponseStates.OK),
        _ => Left(DeviceApiResponseStates.Nah));
}

...where DeviceApiResponseStates is an enum. For simplicity, you can imagine it looks like this...

enum DeviceApiResponseStates {
  OK,
  Nah
}

Those three code blocks are a complete sample of my problem.

I would expect that if I call CreateDevice("jim"), then I would get a Left with a value of Nah, and if I call it with any other string value, I would get a Right with a value of OK.

However, when I try this...

Console.WriteLine((await CreateDevice(""))
  .Match(_ => "Yeah", ex => $"Exception: {ex}"));

... I get Nah, irrespective of the string value.

Anyone able to explain what I'm doing wrong?

[MrYossu]

In case it helps anyone, Mark Seeman pointed out to me that the first lambda in the Match should be _ => ... instead of () => ...

For his explanation, please see this SO answer.

Don't think I can close this discussion.