-
Notifications
You must be signed in to change notification settings - Fork 1.8k
[PM-38743] Honor a partially supplied event date range #8265
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
Changes from all commits
c5daf56
966bcea
6de2880
56dd3b7
d3747cd
e77b321
dacecc7
bfaaa05
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -80,28 +80,34 @@ public async static Task<ObjectResult> HandleAzureEvents(HttpRequest request, | |
| /// <param name="start">start date and time</param> | ||
| /// <param name="end">end date and time</param> | ||
| /// <remarks> | ||
| /// If start or end are null, will return a range of the last 30 days. | ||
| /// If a time span greater than 367 days is passed will throw BadRequestException. | ||
| /// A supplied bound is always honored; the missing bound is inferred from it. | ||
| /// With neither supplied, returns the last 30 days. | ||
| /// With only <paramref name="start"/>, the range runs to the current time. | ||
| /// With only <paramref name="end"/>, the range covers the 30 days before it. | ||
| /// An inverted range is swapped. A range greater than 367 days throws BadRequestException. | ||
| /// </remarks> | ||
| public static Tuple<DateTime, DateTime> GetDateRange(DateTime? start, DateTime? end) | ||
| { | ||
| if (!end.HasValue || !start.HasValue) | ||
| if (!start.HasValue) | ||
| { | ||
| end = DateTime.UtcNow.Date.AddDays(1).AddMilliseconds(-1); | ||
| start = DateTime.UtcNow.Date.AddDays(-30); | ||
| start = end.HasValue ? ThirtyDaysBefore(end.Value) : DateTime.UtcNow.Date.AddDays(-30); | ||
| } | ||
| else if (start.Value > end.Value) | ||
|
|
||
| end ??= DateTime.UtcNow; | ||
|
|
||
| if (start.Value > end.Value) | ||
| { | ||
| var newEnd = start; | ||
| start = end; | ||
| end = newEnd; | ||
| (start, end) = (end, start); | ||
| } | ||
|
Comment on lines
+98
to
101
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This functionality is interesting to me. I know it was existing so perhaps we leave it alone, but I would personally prefer our API to return a This makes it clear that the consumer of the API is responsible for providing a sensible date range, and doesn't let them build bad integrations with our API that mix up the start/end params
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I agree in principle but I think this might be out of scope/need a separate ticket because main is accounting for this backward date correction and so it could break existing code that is supplying the backwards dates. So everyone's code that is supplying bad dates would then break with no warning. What do you think? Do you think it's enough of an edge case to just implement it in this PR and maybe a couple people learn the hard way? @lastbestdev
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I agree this bit is out of scope, and it would be something to discuss with the team if we should remove it. To your point, doing this should include the due diligence of checking our |
||
|
|
||
| if ((end.Value - start.Value) > TimeSpan.FromDays(367)) | ||
| { | ||
| throw new BadRequestException("Range too large."); | ||
| throw new BadRequestException("Date range must be < 367 days."); | ||
| } | ||
|
|
||
| return new Tuple<DateTime, DateTime>(start.Value, end.Value); | ||
| } | ||
|
|
||
| private static DateTime ThirtyDaysBefore(DateTime value) => | ||
| value - DateTime.MinValue < TimeSpan.FromDays(30) ? DateTime.MinValue : value.AddDays(-30); | ||
| } | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,29 @@ | ||
| ο»Ώusing Bit.Api.Dirt.Public.Models; | ||
| using Xunit; | ||
|
|
||
| namespace Bit.Api.Test.Dirt.Public.Models; | ||
|
|
||
| public class EventFilterRequestModelTests | ||
| { | ||
| [Fact] | ||
| public void ToDateRange_OnlyStartSupplied_DoesNotFallBackToThirtyDayDefault() | ||
| { | ||
| var suppliedStart = DateTime.UtcNow.AddDays(-3); | ||
| var request = new EventFilterRequestModel { Start = suppliedStart }; | ||
|
|
||
| var dateRange = request.ToDateRange(); | ||
|
|
||
| Assert.Equal(suppliedStart, dateRange.Item1); | ||
| } | ||
|
|
||
| [Fact] | ||
| public void ToDateRange_WritesResolvedBoundsBackOntoTheModelForDiagnosticLogging() | ||
| { | ||
| var request = new EventFilterRequestModel(); | ||
|
|
||
| var dateRange = request.ToDateRange(); | ||
|
|
||
| Assert.Equal(dateRange.Item1, request.Start); | ||
| Assert.Equal(dateRange.Item2, request.End); | ||
| } | ||
| } |
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.
Nit: you could move the assignment of
endto above this check, and then this line could be simplified to: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.
This wouldn't keep the same value, since
.Dateevaluates to the very beginning datetime for the date it is read from, but that should be no issue. It would be a true 30 days clock time back instead.