Huey will block indefinitely if task returns None

I have a task that returns None. If I do a blocking call on the result r(blocking=True) it will wait indefinitely. Can huey distinguish between None, and a result not being ready?

[coleifer]

Why are you blocking on the result of a task that returns none? Just return a dummy value.

The reason huey does not store None by default is to allow the user to run tasks without filling up the result store with garbage. A result is only removed the result store when it is read. Otherwise there is no “clean-up” process.

Recommendation:

• know what you’re doing - read the docs
• do not enable store_none=True - unless you are periodically cleaning out your results store or you are sure to resolve every result.
• return 0 or some other sentinel value in your tasks if you must - that way your other tasks which do not have a meaningful return value will not clutter up the result store
• know that resolving results can oftentimes be an anti-pattern. If you’re blocking on some computation you initiated, then why do it in huey in the first place?

[coleifer]

I have an ideological hang up here, which I don’t expect you to cater to.None is a value like any other. Ensuring that I never return None is not something I want to do.

This is a design decision of huey. Huey store the results of tasks, which then have to be read in order to be removed from result storage. Because many (most?) users just fire off tasks without resolving the result (e.g., send an email, check if comment is spam, generate thumbnails, etc), we don’t want to fill up the result-store with meaningless results that never get checked (e.g., a million None values for all the tasks you’ve ever executed).

The only other way to handle this would be to force tasks to return a sentinel value, and just ignoring None by default seems much more sane to me.

For the case where you do want to block on a result, then the result needs to be non-None - since None is ignored by default and not put in the result-store in the first place. I think it is better to just return True or something in the case where you want to block, rather than default to storing results for every task – even the ones that do not have a meaningful return value. Huey allows you to do this, though, it’s just not the default – for what I think are obvious reasons.

why blocking would be affected by my decision to store results either

Because you’re blocking on resolving the result.

If you want you can also just add an “on-complete” signal handler instead, depending on your use-case (which isn’t tied to the result store).

https://huey.readthedocs.io/en/latest/signals.html