maennchen

maennchen

I’m trying to fix all dialyzer warnings in quantum for the next big release. There are two errors which I’m not able to solve.

The errors are:

lib/quantum.ex:69: The created fun has no local return
lib/quantum/normalizer.ex:37: Function normalize/2 has no local return

Here is the spec which I think is offending dialyzer.


# Quantum.Normalizer.normalize/2
@spec normalize(Job.t, config_full_notation | config_short_notation) :: Job.t | no_return

Involved Files:

Steps tried to solve the issue:

  • Added no_return to the specs return type
  • Tried to locate a specific function that causes the problem

Both steps were not succesfull.

The current progress can be seen in this WIP PR: https://github.com/c-rack/quantum-elixir/pull/255

Showing Posts 8 to 1

dom

dom

no_return means there is no local return whatsoever, the function can only crash or loop infinitely. If the function can return a value in at least one code path, then it should not be labeled no_return.

Ajwah

Ajwah

@maennchen I was speaking about the past code base. I have not looked at master, but based on what you are saying, if you are using no_return only when raising exceptions, then I agree that such is correct usage of it.
In the past codebase, because you were desperate to resolve that error: Function has no local return, there were multiple cases where the return type was annotated as :: Job.t | no_return
Dialyzer will interpret that as a mere :: no_return, discarding any consideration for Job.t

maennchen

maennchen OP

@Ajwah Thanks for your explanation. I never really understood how we solved the issue until now.

When you‘re saying that we should remove the no_return, do you mean the current codebase? I thought that the no_return is currect there because we are raising exceptions.

Ajwah

Ajwah

@maennchen
I understand that this issue is a few months old and that ever since the code base has advanced significantly.
Nevertheless, I have this same issue in my code base myself, and after a lot of trying I was unable to locate the root issue.
In order to get more insight, I decided to git pull that commit of yours and see if I could resolve the issue.

The issue you were having at that time was simply that @fields contained more types than covered by @typep field

@fields [:name, :schedule, :task, :overlap, :run_strategy, :timezone]
@typep field :: :name | :schedule | :task | :overlap | :run_strategy # :timezone is missing here

Once you add that in, dialyzer works just fine.

BTW: You should also remove | no_return. no_return means that you are dealing with a function call that will not return any value, such as an infinite recursion. By you specifying :: Job.t | no_return, dialyzer unions that to be simply: :: no_return.
Although the error may disappear(which in this case it did not), effectively your spec fails to reflect the actual nature of your code.
It is as if you would have added that as part of the ignore under: dialyzer.ignore_warnings file

maennchen

maennchen OP

If I remove this function clause entirely, I get the same error. So I’m not sure that this is the problem.

NobbZ

NobbZ

Here you require job to be a list. Guessing from the implementation it seems to be a list of configs. That’s not covered by your spec.

maennchen

maennchen OP

Thanks for taking the time to look at the issue :slight_smile:

I already tried adding | Keyword.t to the config_full_notation. This had now effect on the errors. Is this what you mean with your feedback?

Changes Made:

diff --git a/lib/quantum/normalizer.ex b/lib/quantum/normalizer.ex
index a930616..55fd35c 100644
--- a/lib/quantum/normalizer.ex
+++ b/lib/quantum/normalizer.ex
@@ -16,7 +16,8 @@ defmodule Quantum.Normalizer do
            :timezone]
 
   @type config_short_notation :: {config_schedule, config_task}
-  @type config_full_notation :: {config_name | nil, Keyword.t | map}
+  @type config_full_notation :: {config_name | nil, Keyword.t | map} | Keyword.t
+  @type config_notation :: config_short_notation | config_full_notation
 
   @typep field :: :name | :schedule | :task | :overlap | :run_strategy
   @type config_schedule :: CronExpression.t | String.t | {:cron, String.t} | {:extended, String.t}
@@ -32,7 +33,7 @@ defmodule Quantum.Normalizer do
     * `job` - The Job To Normalize
 
   """
-  @spec normalize(Job.t, config_full_notation | config_short_notation) :: Job.t | no_return
+  @spec normalize(Job.t, config_notation) :: Job.t | no_return
   def normalize(base, job)
   def normalize(%Job{} = base, job) when is_list(job) do
     normalize_options(base, job |> Enum.into(%{}), @fields)
NobbZ

NobbZ

config_full_notation and *_short_* are both tuples, but you are guarding for them beeing lists and maps via is_list/1 and is_map/1 in the heads of Quantum.Normalizer.normalize/2..

Since I do assume your tests are passing, it seems as if the definition for your option-types is wrong.

Since it just wraps Quantum.Normalizer.normalize/2 with some prefilled arguments, its just bubbling up. Fix Quantum.Normalizer.normalize/2 and this warning will vanish.


edit

Okay I realise that only one of many heads checks for a list, but that one is causing the issue. Just change the spec to allow a list of those configs as well…

— All posts loaded —

Where Next? Top

Trending in Questions Top

katta
I having some trouble figuring out if I have set myself too strict of standards for my production server. Currently I can handle 75% of r...
New
achenet
Hello, I’m trying to build a basic Phoenix web-app, and I’d like to use Tailwind. However, when I launch mix phx.server, I get an error...
New
bradley
I really like the adapter patterns that ecto, nebulex, waffle, etc. use and would love find something similar for a key management servic...
New
unaware8150
Hello folks! So at work, we are seeing some situations where we have to define some “fixed” strings that are used across the codebase in...
New
Cxx-mlr
I’m working on a small exercise involving update_in/3, and I came up with this solution: data = %{ name: "Periodic Table", category:...
New
ChrisAmelia
I’ve got trouble wrapping my head around the order in which functions are called in this snippet (from Phoenix’s authentication): toke...
New
dillonoconnor
Is there any way to avoid the Hologram compiler running when using iex? It seems like the front-end code could potentially be disregarded...
New

Other Trending Topics Top

GenericJam
Edit: 2026 May 15 - This post is archived. Mob is alive!! Main docs: mob v0.7.11 — Documentation A bit of explanation for the slightly c...
New
garrison
Hobbes is a low-level distributed database for the Elixir programming language. Hobbes provides a simple, safe, and scalable storage lay...
New
budgie
A little off-topic, but I feel like people here have a good head on their shoulders. I used to be quite good at making software. Was luc...
New
KristerV
Hey. Is there anyone here who creates agents in their apps? Not talking about using agents, but creating them. I’m finding it pretty diff...
New
mudasobwa
I fully migrated to my own harness from Anthropic/Gemini and I think it’s time to share it. Welcome DSH, the DeepSeek Harness, fully writ...
New
mcass19
ExRatatui lets you cook up rich terminal UIs in Elixir, powered by Rust’s ratatui via Rustler NIFs. Build interactive terminal applicatio...
New

We're in Beta

About us Mission Statement

Options

Thread Display Mode




Thread Preview

Skip Thread Previews