-
-
Notifications
You must be signed in to change notification settings - Fork 161
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
MonitorSchedule constructor that validates crontab syntax #625
Conversation
Codecov Report
@@ Coverage Diff @@
## master #625 +/- ##
==========================================
- Coverage 73.11% 73.03% -0.08%
==========================================
Files 58 59 +1
Lines 6576 6658 +82
==========================================
+ Hits 4808 4863 +55
- Misses 1768 1795 +27 |
.map(CronToken::Numeric) | ||
.chain(MONTHS.iter().map(|&month| CronToken::Alphabetic(month))) | ||
.collect(), | ||
(0..8) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
with all these ranges, you can use the inclusive range syntax 0..=7
, though in this case specifically, shouldn’t it either be 1..=7
or 0..=6
? TBH, I’m not that familiar with cron syntax.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apparently it should be only 0-6 (inclusive). 7 is included in some implementations, but it is nonstandard, so I will remove it from here and go with only 0 through 6.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Inclusive range syntax seems like a good idea though; I was unaware of it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Although I might restructure this now, since I just read that actually the alphabetic abbreviations for days of the week and months are only permitted in standard crontab syntax when they are the only value; they are not permitted to occur within lists or ranges (although some implementations allow it).
} | ||
|
||
pub fn validate(crontab: &str) -> bool { | ||
let allowed_values = vec![ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe you can use a static once_cell
to avoid doing all these allocations every time:
https://docs.rs/once_cell/latest/once_cell/#lazy-initialized-global-data
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think caching the allowed_values vector would be unnecessary for my proposed use case; the sentry-cli
would be calling this function at most once per run in order to validate the crontab passed in by the user. So unless we anticipate another use case where we call validate
many times per run, I think we can safely keep the function as is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I rewrote this a bit; now the allowed values are defined in a constant
let range = match steprange_split.next() { | ||
Some(range) => range, | ||
None => { | ||
return false; | ||
} | ||
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
let range = match steprange_split.next() { | |
Some(range) => range, | |
None => { | |
return false; | |
} | |
}; | |
let Some(range) = steprange_split.next() else { return false; }; |
I noticed that CI is currently failing because I am using the function Is upgrading the version of Rust we run against in CI trivial enough that we can make the change here, or do I need to rewrite my code without |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
though you should maybe change the implementation to still work on our MSRV. In the SDK we are rather conservative with backwards compatibility, and usually bump it if one of the dependencies does so too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me, apart from the MSRV incompatible changes.
Okay, I have fixed the MSRV issue. How soon can we release a new version with these changes, since I would like to use them in getsentry/sentry-cli#1807? |
* master: tracing: send spans' attributes along with the event ones (#629) release: 0.32.0 Update crate dependencies (#628) feat: bump http to 1.0.0 (#627) release: 0.31.8 MonitorSchedule constructor that validates crontab syntax (#625) fix(docs): Fix some doc errors that slipped in (#623) docs(tower): Mention how to enable http feature from sentry crate (#622) build(deps): bump rustix from 0.37.23 to 0.37.25 (#619)
I will want to use the new
MonitorSchedule::from_crontab
in getsentry/sentry-cli#1807