Fix double wrapping({:ok,{:ok, value}}) problem on tuple policy with source KV

[altuntasfatih]

Heys,
We used the tuple policy to properly return the data to the caller for fine-gradient error handling.
However, we faced this issue on the KV source.
It wraps data by the ok tuple again without controlling whether the data is the ok tuple or not. So it wraps, then data becomes {: ok,{: ok, value}}.

I have added the following line code in two asterisks to the KV fetch function. It does not wrap again if the data is an ok tuple.

 case Map.fetch(batch, id) do
          :error -> {:error, "Unable to find id #{inspect(id)}"}
          {:ok, {:error, reason}} -> {:error, reason}
          ** {:ok, {:ok, item}} -> {:ok, item} **
          {:ok, item} -> {:ok, item}
        end

Actually, The code checks the error tuple but not the ok tuple case. I guess that was forgotten somehow.

In addition,

• I have replaced the then/2 function with an anonymous function to fix the pipeline
• I have replaced the use Mix.Config statement with import Config to remove the deprecated warning.

[altuntasfatih]

Could you review it? @akoutmos, @benwilson512, @jadlr, @mbuhot

[altuntasfatih]

Could you approve again to run workflows? benwilson512

[altuntasfatih]

@benwilson512, there is a conflict between .tool-versions and pipeline. The pipeline works on Elixir-1.10-11&OTP-22-23, whereas the .tool-versions works on Elixir-1.12-13&OTP-24. This causes problems. We should upgrade the pipeline.

For instance, the mix format works on both versions differently. that is the reason the pipeline says the files are not formatted.

At local, OTP24-Elixir1.13 says the format is okay, but Otp 23-elixir.1.11 says it is not formatted.

[altuntasfatih]

I have updated the pipeline as well. @benwilson512

[altuntasfatih]

I have amended it. Could you check again @benwilson512 ?

[benwilson512]

@altuntasfatih the primary blocker here is that this is technically a breaking change. I'm not clear whether this was a bug or just bad design, but if anyone has code out there that relies on this it will break. We are already kicking off a 2.0 version now so I think we can include that with this.