Martin Atkins

One additional thing I thought of in the meantime: modules that were written for Terraform rather than for OpenTofu might include unused input variables and local values because Terraform does...

The use-case in https://github.com/opentofu/opentofu/issues/2619 directly contradicts our basis for accepting this request, so we should probably make a decision on that before we move forward any further here.

I've written a small tool that makes a best-effort to detect unused input variables and local values in an OpenTofu/Terraform module: [`tofu-unused-decls`](https://gist.github.com/apparentlymart/316fc9f598fae1603fd4fb881c6761df). I wrote this in the hope that we...

Hi all! The maintainers discussed this again today and so I want to share some new context from that discussion. We originally approved this proposal _in principle_ (pending RFC) before...

Hi @rdhar! Sorry we apparently missed replying to this sooner. I think the trick with this request is that it hinges on how exactly someone defines "changes pending". The current...

Thanks for this suggestion, @ari-becker. I think a crucial detail in a process like this is what exactly would be recorded in the write-ahead log and how OpenTofu would react...

Thanks for that additional context, @ari-becker. I think where I'm getting stuck here is that it relies on the configuration containing enough information to produce what you called "idempotency keys",...

Great, thanks for confirming! It seems to me that keeping a separate "write-ahead log" would only be useful if it were stored in a different failure domain from the main...

Okay, I understand now what you were aiming to achieve with the suggestion of a write-ahead log, and I think this confirmed for me that the granular state storage mechanism...

Hi @bryan-rhm! Thanks for sharing this use-case. From your framing of the problem I understood this as something you'd likely want to set only for production and not for staging/development...