Thanks for the great addon!

I believe there's an off-by-one error in the DelayPolicy. The first retry takes the time at position 1 in the array, and the last retry happens more or less immediately since delay[delay.length] is undefined. If you look at this test, the first retry happens after 200ms, the second after 300ms, and the last immediately. I put some logging in to test this.

Hi, I get this error in console:

Error while processing route: index (0 , _emberConcurrency.task)(...).enqueue(...).maxConcurrency(...).retryable is not a function TypeError: (0 , _emberConcurrency.task)(...).enqueue(...).maxConcurrency(...).retryable is not a function

task modifiers look like this: .enqueue().retryable(backoffPolicy)

ember-concurrency-retryable seems to be correctly installed because backOffPolicy has a value.

using Ember 3.2.2

For looping tasks (e.g. those with while(true) { ... }), if the task is retried successfully, the next time it fails, it will only be retried if there are available delays left in the policy (in the context of DelayPolicy-based policies). This seems counter-intuitive, so it should probably be changed so that successfully retrying the task clears the slate. There may be some instances where that wouldn't be the desired behavior, but that seems outside of the typical use-case and should be implemented in a custom policy.

"ember-concurrency": "^2.3.7",
"ember-concurrency-retryable": "1.0.0",
"ember-source": "~3.28.11",

app.js:

import 'ember-concurrency-retryable';

It's trying to do something with ember concurrencys' Yieldable?:

class RetriedSignalYieldable extends _emberConcurrency.Yieldable

This ember-concurrency PR moved around some internals (preserving the old names w a deprecation warning in cases where I know addons such as this made use of private/intimate API).

When you have a sec, could you run against this PR and fix any imports to private APIs and let me know if I missed anything?

Thanks a lot for this wonderful addon! I am in process of upgrading my code to the latest version of Ember and ember-concurrency. For Eg., Am changing the tasks from:

setupTask: task(function * () {}).drop()

to:

@dropTask *setupTask() { };

How does this work in case of retryable tasks? Any pointers on how to migrate the following code to be compliant with the latest Ember concurrency will be much appreciated!

fooTask : retryable(task(function * () {
   .....
}).drop().evented(), retryPolicy);

Any thoughts/plans on adding a decorator for the add-on?

for reference, here are ember-concurrency decorators: https://github.com/machty/ember-concurrency-decorators

The addon has sufficient API surface and complexity at this point that it's worth taking a look at building in a documentation site.

First of mind approach: https://ember-learn.github.io/ember-cli-addon-docs/latest/

Would be great to have a place to put some live examples / a cookbook of sorts.