Poison.decode/1 invalid method signature.
KamilLelonek opened this issue ยท 7 comments
According to the documentation:
decode(iodata, options \\ [])
decode(iodata, Keyword.t) ::
{:ok, Poison.Parser.t} |
{:error, :invalid} |
{:error, {:invalid, String.t}}
The invalid cases are either {:error, :invalid}
or {:error, {:invalid, String.t}}
.
However, have a look at this example:
iex(1)> Poison.decode "{"
{:error, :invalid, 1}
so we are getting {:error, :invalid, integer()}
.
And that one:
iex(18)> Poison.decode "}"
{:error, {:invalid, "}", 0}}
which is basically: {:error, {:invalid, String.t(), integer()}}
Aren't docs up to date then?
I am seeing the same issue on 3.0.0
and 3.1.0
. Looks like it is due to this commit: 50f25b7
This is acceptable because of the major version bump, and surely would have been mentioned in the CHANGELOG if there was one.
However, this change was then removed: a4208a6#diff-574cf330de0ee486ba021c9eaa1f0e7bL42 so it seems that 4.0.0
will have the original 2.X
behavior.
@KamilLelonek -- Can you verify the version you were using when conducting the above test?
Perhaps @devinus can explain the reasoning for the change and subsequent revert?
From what I see, I was using 3.1.0
version when this issue occurred.
Bump.
@alakra -- the conclusion above was that this issue appears to be limited to 3.0.0
and 3.0.1
. Please include what version you are using and also try upgrading first.
this issue appears to be limited to
3.0.0
and3.0.1
Not really. I'm using 3.1.0
.
Yeah sorry, my mistake, the fix is only on master
. And creating a new release would be a major version bump.
So how is this going?
This kind of problem is the prime candidate to create a bugfix-release for 3.1.X that has updated documentation to match the actual behaviour that Poison has.