To struct or not to struct, Decode or not decode

So, I am working with my IPFS client library and I’ve run into dialyzer hell. The code is kinda working fine, but Dialyzer is not happy with me. Before I ignore it completely, I want to make sure I’m not guilty of an anti-pattern.

The IPFS API returns stuff like this:

  "BlocksReceived": "<uint64>",
  "BlocksSent": "<uint64>",
  "DataReceived": "<uint64>",
  "DataSent": "<uint64>",
  "DupBlksReceived": "<uint64>",
  "DupDataReceived": "<uint64>",
  "MessagesReceived": "<uint64>",
  "Peers": [
  "ProvideBufLen": "<int>",
  "Wantlist": [
      "/": "<cid-string>"

I thought it would be nice to make structs for these types of return values, instead of just passing the JSON back to user. I have made structs to build these, where I have structs for wantlist and CIDs.
myspace-ipfs/wantlist.ex at develop · bahner/myspace-ipfs · GitHub
myspace-ipfs/common.ex at develop · bahner/myspace-ipfs · GitHub

Then I use the structs as components for complex structs and so forth. I like the wantlist.keys notation that they give me when I structure the keys as (existing) atoms.

But when I take a result and pass it to Jason.decode, then dialyser becomes really unhappy. The error messages blow up in length, as I try to fix them. And, hence, I suspect I’m doing it wrong.

Please note. I can’t always use only use the Tesla.Middleware.Jason for this, as the API sometimes returns \n<\n when data is streamed, and there is no known end to the data, so it canæt generate lists, and hence not proper JSON.

Am I doing it wrong by trying to massage the data and should I just pass the JSON strings to the user? Or just let the middleware do its best and decode the lines as they come in.

1 Like

Can you post an example of the error messages or some example code? I’m not quite following what you’re passing to Jason.decode.

I don’t see anything immediately “uh-oh” in those files.

If I try this function: (Whish doesn’t involve Jason.decode here. So it creates less confusion for this disciussion)

Like this:

  def put(data, opts \\ []) do
    |> post_multipart("/dag/put", query: opts)
myjson = "{\"Key\":\"Value\",\"Bar\":[1,2,3]}"
# It yields:
# which Tesla correctly turns into:
  "Cid" => %{
    "/" => "bafyreidicaztrpvtfzvq3xolltjotbs6hfmiwv5qzbtimd5245aaw2y6yq"

BUt i want to turn this into a struct, so I have a function which iuses Recase to turns keys into existing atoms and snake case them:

 @spec snake_atomize(map) :: map
  def snake_atomize(map) when is_map(map) do
    |> Recase.Enumerable.convert_keys(&Recase.to_snake/1)
    |> Recase.Enumerable.convert_keys(&String.to_existing_atom/1)

When I add this in the pipeline my result is as expected:


%{cid: %{/: "bafyreidicaztrpvtfzvq3xolltjotbs6hfmiwv5qzbtimd5245aaw2y6yq"}}

But then the warnings start, I want to extract the cid, so I pipe like so:

  @spec put(binary, opts) :: {:ok, MyspaceIpfs.RootCid} | {:error, any}
  def put(data, opts \\ []) do
    |> post_multipart("/dag/put", query: opts)
    |> snake_atomize()
    |> Map.get(:cid, nil)

# Which correctly yields:
%{/: "bafyreidicaztrpvtfzvq3xolltjotbs6hfmiwv5qzbtimd5245aaw2y6yq"}

And then the warning starts.

This is not the only place, but it’s a pretty simple example.

What warnings? Where do they appear? I ask because I’ve seen plenty of very strange messages in-editor when elixir-ls gets confused, but those usually disappear after cleaning _build etc and don’t show up in mix dialyzer.


In VS Code, as I write. But I have a makefile, which cleans _build and I do that ever so often.

But I assume from your reply, that I shouldn’t worry too much about this.

It would be helpfull if you can post the output of mix dialyzer here as well. In case you do not have it in your deps you can add it: dialyxir | Hex

It seems that you have elixir-ls enabled in your vscode but sometimes it might be easier to see the output on the command line. (sometimes elixir-ls is “wrong” or needs to catch up)

Looking briefly at your code I think the return spec it wrong here:

I’m guessing you are missing .t() in your :ok tuple.

I personally have dialyzer disabled in my vscode-elixirls settings because I find the warnings very distracting for WIP code. When I am closer to a final version, I run it on the command line to check my assumptions and catch things I missed.


Fun thing about elixir_ls is that it doesn’t compile to ./_build, but to ./.elixir_ls (specifically ./elixir_ls/build/test). I don’t think I’m alone in occasionally zapping the .elixir_ls directory.

Another fun thing is that dialyzer is almost always correct although often cryptic. (When I say fun, I really mean infuriating.)

As @hlx says, I’d be inclined to also include dialyxir as a dependency (only: [:dev, :test], runtime: false) so you can run mix dialyzer from the terminal and fix the errors, eg with the capitalisation typo MySpaceIPFS instead of MyspaceIPFS, eg here

Also as @hlx alludes {:ok,MyspaceIpfs.RootCid}should probably be{:ok, :MyspaceIpfs.RootCid.t()}` (which I see you’ve defined in the struct).

1 Like

Thanks. I appreciate the advice. I have installed the dialyxir dependency and that renders the feedback much more easy to read. I will disable the dialyzer in VS Code and add “mix dialyser” to the test / compile process somewhere.

I took in the replies I got and learned that I was trying a bit too hard. So i loosened up trying to cram everything into a specific type in the api-module. Refactored the whole thing, in a way that means I have to do a little more work over each function, but have more control. Using the mix dialyzer allowed be to see the errors more clearly in the shell, than as small windows in VS Code.
The hint, that dialyser is usually right made me follow the advice to get a better picture of what iot wanted. And it worked. Thanks.