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

add a default bounce expiration #866

Merged
merged 4 commits into from Feb 4, 2016
Merged

add a default bounce expiration #866

merged 4 commits into from Feb 4, 2016

Conversation

ssalinas
Copy link
Member

@ssalinas ssalinas commented Jan 28, 2016

Don't allow a bounce that will go on forever. Defaults to 60 minutes and shows in the ui as:
screen shot 2016-01-28 at 9 14 55 am

actionId = bounceRequest.get().getActionId();
message = bounceRequest.get().getMessage();

if (bounceRequest.get().getDurationMillis().isPresent() && !actionId.isPresent()) {
Copy link
Contributor

@wsorenson wsorenson Jan 28, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This logic was changed

Copy link
Member Author

@ssalinas ssalinas Jan 28, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, I'll check against staging to see what changed

Copy link
Contributor

@wsorenson wsorenson Jan 28, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, now that I look again - are we now saying it's impossible to have unlimited bounce?

If so, what will you do if someone enters a negative value for this configuration? Need to have validation on it or allow people to set it to 0/negative to indicate that they don't want to use this feature.

In which case, we'd only set actionId if there was a duration set.

Copy link
Member Author

@ssalinas ssalinas Jan 28, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you think we should still create an expiring object either way? One thing I realized in writing this is that if we don't create the expiring object, there isn't actually a way to cancel the bounce (without doing a janky pause/unpause)

Copy link
Contributor

@wsorenson wsorenson Jan 28, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point, maybe just setup the config to validate that this must be non-zero, positive, then it's not an issue. I think you can do that with annotations. Someone could set it really high.

@ssalinas
Copy link
Member Author

ssalinas commented Jan 28, 2016

Ok, reworked this a bit. Not reconstructing the object anymore, just getting the durationMillis slightly differently for bounces in SingularityExpiringUserActionPoller so we can use the default and added a @Min for the config value. Tweaked the UI to show default value as well if there isn't a duration present for bounce

@tpetr tpetr modified the milestones: 0.4.9, 0.4.10 Feb 2, 2016
ssalinas added a commit that referenced this issue Feb 4, 2016
@ssalinas ssalinas merged commit 283287f into master Feb 4, 2016
2 checks passed
@ssalinas ssalinas deleted the default_bounce_expire branch Feb 4, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants