Error on order_num when creating rewrite rules

[mapperr]

Hi!

I was trying to create a bunch of rewrite rules to enable the 'tag' thingy with the plus symbol made popular by google (I guess).

So, I just bumped from version 2023.7.12 to 2024.6.6 and renamed the resource from migadu_rewrite to migadu_rewrite_rule.
That the resource I'm using:

resource "migadu_rewrite_rule" "plus" {
  for_each = merge(local.all_mailboxes, local.aliases)

  domain_name     = local.my_domain
  name            = "${try(each.value.local_part, each.value.alias)}_plus"
  local_part_rule = "${try(each.value.local_part, each.value.alias)}+*"

  destinations = [
    "${try(each.value.local_part, each.value.alias)}@${local.qilab_domain}",
  ]
}

But with the new version I get:

│ Error: Provider produced inconsistent result after apply
│
│ When applying changes to migadu_rewrite_rule.plus["myname"], provider "provider[\"registry.terraform.io/metio/migadu\"]" produced an unexpected new value: .order_num: was cty.NumberIntVal(0), but now cty.NumberIntVal(4).
│
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.

Those are some things I tried that unfortunately led to the same error:

• delete the rewrites and create them from scratch
• set the order_num property to 0 for all elements of for_each (I know that's stupid, but I tried first, thinked after xD)
• set the order num to a sequential number for each element of the for_each (with the help of the index terraform function)

None of that worked out, I haven't got an idea of the problem, It's like I'm trying to set order number from the api, but the api returns an order number that do not match the one I'm specifing, so terraform gets angry. But it's just a wild hypotesis.

[sebhoss]

Ok thanks for letting me know & sorry this is not working at the moment. I'll take a look at let you know as soon as possible ❤️

[sebhoss]

Yeah so I've contacted Migadu support about this because currently there does not seem to be a way to specify the order number at all. It is always computed at their backend based on the currently available rewrites. This is an issue for the current implementation in this provider because I kinda assumed that I can modify each rewrite rule on their own.

I think if the current API behavior stays as-is, there are two options:

1. Do another breaking change to expose a single migadu_rewrite_rules (plural here) resource that takes all rewrites for a single domain and applies them in the order they are given in the resource. Changing that list of rewrites would cause the deletion of all existing rewrites, before re-applying them all in the correct order again.
2. Ignore order number completely and assume that all rewrites are distinct enough anyway so that ordering does not matter.

Option 2 is far easier and would work fine in your case I believe but it obviously breaks for people who require precise control of the ordering. So I'll wait for the response from their support and probably go with option 1.

[sebhoss]

So just a small update here: The Migadu support wrote back a while ago and acknowledged that there is a 'problem' in their API and that they are working on it. I have not heard from them since then and I have been busy with work myself so I do not expect things to move forward here anytime soon..

[mapperr]

Yeah, I know what you mean:
some time ago I saw a news on their website showing the feature to add a forwarding address through the api, I asked support when it will be available and they said "soon".

It was about a year ago xD