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

Document optional cleanup #86

Closed
SeanFeldman opened this issue Jan 29, 2019 · 3 comments
Closed

Document optional cleanup #86

SeanFeldman opened this issue Jan 29, 2019 · 3 comments

Comments

@SeanFeldman
Copy link
Owner

SeanFeldman commented Jan 29, 2019

The plugin looks at the TimeToLive property of the message sent out and sets a custom blob metadata _ValidUntilUtc if the value is other than TimeSpan.MaxValue if found.

In case it's deemed appropriate to remove the attachment blob, the receiving party could use blob ID represented by custom metadata configured using plugin confusion API in conjunction with the container name.

For receive only configured plugin, blob URI is provided via blob URI custom metadata.

@adnanrahat
Copy link

Couple options come in my mind

  1. Delete the blob at the end of AfterMessageReceive() has successfully retrieved the message from the blob. However, the risks of a failure happening in MessageReceiver code (which I think is called after the plugin method is invoked) need to considered.
  2. Set some policy to expire the message after some time. https://docs.microsoft.com/en-us/azure/storage/blobs/storage-lifecycle-management-concepts

@SeanFeldman
Copy link
Owner Author

SeanFeldman commented Jan 29, 2019

Both options you've raised @adnanrahat don't really belong to the plugin itself and are heavily influenced by certain business rules. There are additional cases I can think of that cleanup strategy is difficult. For example, message that is an event. Which subscriber should perform the cleanup? How do individual subscribers know when the last subscriber has finished a successful processing of the message?

As for the Storage Lifecylce Management - again, that's a business decision that should not be mixed with the plugin implementation. As a builder of the system, you are in a better position to define the policy. Not the plugin. You might be deleting after certain period of time. Or archive attachments to follow some sort of compliance. Or you might want to delete based on some categorization based on blob metadata (not supported yet).

Given all these edge cases, I lean towards leaving cleanup process out of the plugin and have it implemented according to the business rules of the users of the plugin. And that's the reason documenting what can be done is welcomed, but implementing any cleanup will have way too many edge cases that will never do the job well for everyone.

@SeanFeldman
Copy link
Owner Author

Cleanup section added.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants