Roadmap

[joeblew99]

This is working fine for me.

I was wondering , since its a newish project if you are thinking about a roadmap or suggestions :

1. Retry
2. Audit trail / logging
3. this could be related to just logging and log shipping, and so is normally something a user of the package would do though, but just logging using the stand log package would mean that logrus etc would automatically work with it.
4. Config driven. This one is pretty useful , but curious if others would use it? The idea is to be able to describe the various tasks and times,. Cobra and viper would be the obvious way to do it, because it would also allow running certain tasks from the CLI, and it would be able to use the config.

Thanks in advance.

[marksalpeter]

Hi @joeblew99! I have some questions about your suggestions

1. Retry: What do you mean by retry? How do you propose it should be implemented. Can you write up a use case for it?
2. Logging: What do you want to see logged by the scheduler? Why not just log things in the funcs you pass to do? Again, a use case would be super helpful.
3. I'm not familiar with cobar or viper. Go is a compiled language, so it might be hard to load a func with logic in it efficiently. Why not just compile it?

[mre]

A retry functionality would be highly appreciated. In my case I have an API which I want to query every five minutes. Sometimes the query fails. In this case I would like to retry the query automatically. Integrating this into gocron would greatly reduce the complexity of error handling since I don't need to implement the retry handling for every task myself.

Here's how it could look like:

gocron.Every(5).Minute().Do(query).Retry(3)

One could add the option to wait between retries. This is commonly referred to as "backoff". Example:

// Retry after 1, 2 and 4 seconds
gocron.Every(5).Minute().Do(query).Retry(3).Backoff(gocron.Backoff.exponential)

Other schedulers like ticktock (seems to be unmaintained) provide this functionality.