basket expiration

[carloshorn]

Feature Description

It would be great, if a basket could be configured with an expiration time or lifespan. After expiration, the basked would be scheduled for deletion. This could be beneficial to in-memory request storage as automatic clean-up.

The idea is inspired by the 30 minute expiration of https://postb.in/.

Impact on Existing User Workflows

I have not yet checked the code (I can read it, but would not call myself a Gopher) to give an idea where this feature would have impacts and therefore could cause some concerns.
Regarding interfaces, I could imagine to have the possibilities to give a default value for all baskets on the server config, and also pass a basket specific value on the creation request. The expiration time should also appear in the basket info which would add an extra field to the basket response model. Logically, the backward compatible default would be a never value.

[darklynx]

Hi @carloshorn

Thank you for your interest in request baskets service!

I like the feature that you have described and it would fit to the service quite well including the service level default expiration configuration for all created baskets. I would definitely dive in to implement it once I have a time for, but I'm also open to accept PRs with the feature implementation.

One extra-thing comes to my mind about basket expiration is the sliding time to expire the basket vs. fixed time: expiration time of a basket is prolonged every time the basket receives requests on the collecting end-point. Both strategies make sense and probably creator of a basket should have a choice between these two.