Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

worklist naming change to be more descriptive #1212

Open
petersilva opened this issue Sep 6, 2024 · 0 comments
Open

worklist naming change to be more descriptive #1212

petersilva opened this issue Sep 6, 2024 · 0 comments
Labels
Design impacts API, or code structure changes Developer not a problem, more of a note to self for devs about work to do. Discussion_Needed developers should discuss this issue. Documentation Primary deliverable of this item is documentation enhancement New feature or request

Comments

@petersilva
Copy link
Contributor

So... in worklists, there are the following sublists:

  • incoming ... messages from gather or retry...
  • ok ... processed successfully.
  • failed ... tried to do the work, it failed, will be queued to retry later.
  • rejected... will not attempt transfer/work. reasons:
    • accept/reject
    • mtime (too new, too old.)
    • duplicate (checksum match)
    • metadata mismatch (mtime of message older than what we already have.)

So when we attempt to retrieve a message... if it fails, whether it goes to failed or rejected depends on why it failed... for a 404... it would go to rejected... It isn't really rejected, it's actually failed in a way that retry will not help with, so we should not be putting it on retry queue.

  • I think failed would better be called... retry_later to better describe the purpose of putting messages there.

  • I think rejected is better described as discard

Making this change, is a breaking API change, since all plugins need to be modified, as they use the worklists.

It seems like an improvement in readability/ease of understanding... but... dunno... maybe not worth it.

@petersilva petersilva added enhancement New feature or request Design impacts API, or code structure changes Developer not a problem, more of a note to self for devs about work to do. Documentation Primary deliverable of this item is documentation Discussion_Needed developers should discuss this issue. labels Sep 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Design impacts API, or code structure changes Developer not a problem, more of a note to self for devs about work to do. Discussion_Needed developers should discuss this issue. Documentation Primary deliverable of this item is documentation enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant