This message was deleted
hmm that’s seems odd. let me know if installing the rewrite plugin fixes it
@srijken I’m going to test the dedup tomorrow and push out a release and finish up the server side stats
if you have any objections let me know :)
I noticed something with the .net client the other day and was wondering if you guys think we should fix it now before we release
if you take a look at the plugins.. the web api and mvc plugins run 100% of the time
and they set user info and do request info even if it’s already been set
so if you have an app that has both web api and mvc the web api stuff will run before mvc but will be taken out..
the issue with all of this is that we have a private info plugin that runs really early to set the user info to machine name..
then other things run and the web api plugin is towards the end that looks up the user info from the request
wondering if we need to make a service that is injected by mvc / web api for getting the user and falls back to environment.username
we’d need to define a interface and di helper to resolve the user identity
UserInfo GetUserIdentity(context)
IGetUserIdentity or something like that
what do you think
think it should fall back to environment.username if the interface doesn’t return anything?
@ejsmith "I wanted to use your product in Xamarin solution(Android/iOS)... Which is provided via Pcl as far as I can understand... And it seemed to me like it's not storing unsent exceptions, so I looked at other solutions…"
with microsoft making xamarin free.. maybe it’s time we invest in a dedicated xamarin client that uses the pcl base..
pcl
I think we can simplify things in the client then.
with the TFMs
TFM?
hey guys, I've been out of town for the past three days and didn't really get to read much on the PR I submitted
based on the feedback, I wonder if I should abandon it and let you guys discuss further, it seems like maybe you have larger plans
no pressure over here, we know you guys work on this in your free time and it’s greatly appreciated
Yeah, I think it was good to take a stab at it. I think there just needs to be some discussion around it.
We know we need to do it, just what’s the best way long term.
@moswald yeah, we are just trying to figure out what the best approach is and you got the discussion started and I think that is awesome. I think we just need to iterate from there.
we just want to make sure that we come up with a solution that we all agree with.
I’m testing the .net client for release and then I’ll take a look at the pr and add some feedback
I saw that there was activity on it this weekend I just was busy with family
@srijken seems to be working really good :D
@ejsmith when I get this user stuff done
I’m adding the ability to view the raw event json
I need it like every day
@srijken I’m taking a look into this
seems like when I click between two different errors multiple times I get a series of them
and should be quick
it appears we are doing
hashCode = (hashCode * 397) ^ TotalPhysicalMemory.GetHashCode();
hashCode = (hashCode * 397) ^ AvailablePhysicalMemory.GetHashCode();
hashCode = (hashCode * 397) ^ ProcessMemorySize.GetHashCode();
hashCode = (hashCode * 397) ^ (ThreadName == null ? 0 : ThreadName.GetHashCode());
hashCode = (hashCode * 397) ^ (ThreadId == null ? 0 : ThreadId.GetHashCode());
which the memory one for process memory is changing by .1mb and causing it to not be deduplicated
wondering if thread id is changing it as well
total memory is fine
but I don’t think the memory and thread ones should be there
I’m seeing reference id interferring as it’s stored in a cookie
so it’s changing that on request info
should we remove cookies from the gethashcode logic too
?
why would we do that?
if the cookies are different, don’t we want to see them?
because were updating the lastreferenceid cookie value and then it’s not deduped
yeah I guess but if everything else matches then it’s kind of a dup no?
if we can skip that one
that would be good.
yeah I’ll add logic to skip that key on gethashcode
you think we should remove the threadid,thread name, available memory and process memory size from gethashcode
to me those are things that could change alot
but having those may help track down multithreaded issues
DuplicateCheckerPlugin: Checking event: with hash: -1999577676
DuplicateCheckerPlugin: Checking event: with hash: -25846723
DuplicateCheckerPlugin: Checking event: with hash: -25846723
DuplicateCheckerPlugin: Checking event: with hash: -688792890
DuplicateCheckerPlugin: Checking event: with hash: -25846723
DuplicateCheckerPlugin: Checking event: with hash: -1999577676
DuplicateCheckerPlugin: Enqueueing event with hash:-1999577676 to cache.
DuplicateCheckerPlugin: Enqueueing event with hash:-25846723 to cache.
DuplicateCheckerPlugin: Enqueueing event with hash:-1999577676 to cache.
DuplicateCheckerPlugin: Enqueueing event with hash:-25846723 to cache.
DuplicateCheckerPlugin: Enqueueing event with hash:-688792890 to cache.
DuplicateCheckerPlugin: Enqueueing event with hash:-25846723 to cache.
DuplicateCheckerPlugin: Checking event: with hash: -25846723
DuplicateCheckerPlugin: Checking event: with hash: -25846723
DuplicateCheckerPlugin: Checking event: with hash: -688792890
DuplicateCheckerPlugin: Checking event: with hash: -25846723
DuplicateCheckerPlugin: Checking event: with hash: -1999577676
DuplicateCheckerPlugin: Enqueueing event with hash:-1999577676 to cache.
DuplicateCheckerPlugin: Enqueueing event with hash:-25846723 to cache.
DuplicateCheckerPlugin: Enqueueing event with hash:-1999577676 to cache.
DuplicateCheckerPlugin: Enqueueing event with hash:-25846723 to cache.
DuplicateCheckerPlugin: Enqueueing event with hash:-688792890 to cache.
DuplicateCheckerPlugin: Enqueueing event with hash:-25846723 to cache.
were using a concurrent queue
and it’s almost like it’s blocking
yeah I removed them now running into some kind of issue with the above
seems like there getting blocked when you queue up a bunch of them and then they are allowed
:D
got awesome logging now in our client unit tests
Checking event: with hash: 738490750
Checking event: with hash: -717263284
Enqueueing event with hash:-717263284 to cache.
Checking event: with hash: -717263284
Enqueueing event with hash:-717263284 to cache.
Checking event: with hash: -717263284
Enqueueing event with hash:-717263284 to cache.
Enqueueing event with hash:738490750 to cache.
Checking event: with hash: -717263284
Checking event: with hash: -717263284
Checking event: with hash: -717263284
Enqueueing event with hash:-717263284 to cache.
Checking event: with hash: -717263284
Enqueueing event with hash:-717263284 to cache.
Checking event: with hash: -717263284
Enqueueing event with hash:-717263284 to cache.
Enqueueing event with hash:738490750 to cache.
Checking event: with hash: -717263284
Checking event: with hash: -717263284
def having a threading issue
with the plugin
changed the forloop to a parallel 4 and everything broke loose
@srijken would you be willing to help me look into why the concurrent ones are failing? I added unit tests with improved logging
I think we might need to add some locking code in there
which is both scary and sucks
and it increased the run time quite a bit
I’m also seeing a weird issue where 1 out of 4 runs fails with invalid hashcode
Enqueueing event with hash:-1799816918 to cache.
Adding event with hash:-1799816918 to cache.
Enqueueing event with hash:825815748 to cache.
Ignoring duplicate event with hash:-1799816918
Ignoring duplicate event with hash:-1799816918
Ignoring duplicate event with hash:-1799816918
Ignoring duplicate event with hash:-1799816918
Ignoring duplicate event with hash:-1799816918
Ignoring duplicate event with hash:-1799816918
Ignoring duplicate event with hash:-1799816918
Adding event with hash:-1799816918 to cache.
Enqueueing event with hash:825815748 to cache.
Ignoring duplicate event with hash:-1799816918
Ignoring duplicate event with hash:-1799816918
Ignoring duplicate event with hash:-1799816918
Ignoring duplicate event with hash:-1799816918
Ignoring duplicate event with hash:-1799816918
Ignoring duplicate event with hash:-1799816918
Ignoring duplicate event with hash:-1799816918
same code paths and event being generated
DeduplicationBenchmarks_IdenticalExceptions, 116 runs
DeduplicationBenchmarks_IdenticalExceptions - 0.01ms
DeduplicationBenchmarks_LargeEventsFromFiles, 103 runs
DeduplicationBenchmarks_LargeEventsFromFiles - 0.30ms
DeduplicationBenchmarks_RandomExceptions, 110 runs
DeduplicationBenchmarks_RandomExceptions - 0.01ms
that’s what it was before my change
lets see what it is on the build server now
@ejsmith @srijken feedback on this is greatly appreciated: exceptionless/Exceptionless.Net@9a34941
DeduplicationBenchmarks_IdenticalExceptions, 114 runs
DeduplicationBenchmarks_IdenticalExceptions - 0.01ms
DeduplicationBenchmarks_LargeEventsFromFiles, 214 runs
DeduplicationBenchmarks_LargeEventsFromFiles - 0.31ms
DeduplicationBenchmarks_RandomExceptions, 112 runs
DeduplicationBenchmarks_RandomExceptions - 0.01ms
didn’t seem to slow it down any
@frankebersoll https://github.com/sergeyt/karma-typescript-preprocessor/issues/30#issuecomment-99655328 looks like the tooling is starting to support typescript a bit better :)
agree on removing those properties from gethashcode
locking thing.. it’s weird that it’s necessary?
concurrent queue should fix concurrency issues
DuplicateCheckerPlugin: Checking event: with hash: -1999577676
DuplicateCheckerPlugin: Checking event: with hash: -25846723
DuplicateCheckerPlugin: Checking event: with hash: -25846723
DuplicateCheckerPlugin: Checking event: with hash: -688792890
DuplicateCheckerPlugin: Checking event: with hash: -25846723
DuplicateCheckerPlugin: Checking event: with hash: -1999577676
DuplicateCheckerPlugin: Enqueueing event with hash:-1999577676 to cache.
DuplicateCheckerPlugin: Enqueueing event with hash:-25846723 to cache.
DuplicateCheckerPlugin: Enqueueing event with hash:-1999577676 to cache.
DuplicateCheckerPlugin: Enqueueing event with hash:-25846723 to cache.
DuplicateCheckerPlugin: Enqueueing event with hash:-688792890 to cache.
DuplicateCheckerPlugin: Enqueueing event with hash:-25846723 to cache.
^^ What’s wrong with that?
except for the hash calculations
well those are all called concurrently
and they are all enqueued
when some of those should be ignored
look
-2584673 all of those were enqueued and were the same number
same for the -1999577676
yeah there is something goofy going on
it’s enqueueing them too often
idealy no lock would be good but if you look at it without one it’s chaos
I’m pretty convinced it should work without the lock
the lock doesn’t fix the issue either right?
xunitexceptionlesslog
it does part of the time
still fails randomly
nothing stood out to me
tried breaking it down
I think I foudn it :P
hm it works for me
@ejsmith just with dedup on multithreaded
@srijken I can reproduce it everytime by triggering new mvc errors
just click it the same error multiple times (api post and api get links)
I noticed that .Data implements its own GetHashCode(), should use the extensions one
GetCollectionHashCode()
ok
weird
data should be exactly the same on all of those
nice catch
that one will order the keys before calculating the hashcode
it’s not what’s causing the problem though
@srijken have you figured out a good way to see how gethashcode is being miscalculated
also, does each line need to be (dashcode ^ 397) or just the whole thing on the return?
it’s what R# generates. I read up on why it did that, and it sounded like a good idea
397 is a fairly large prime number
weird thing is it seems to happen on that unit test ever few executions
wonder if it has to do with the module id calculation
cause that changes
maybe modules need to be sorted?
if so that’s a pita
do we even care about module info
@ejsmith
too me just because a module is added or removed an error occurs doesn’t mean anything even on module load errors
are they different?
I compared them with beyond compare and they were all the same on my machine (checked 6 dupes that came through) only thing that was different was the reference id
not the ID either
id, date and reference id stuff was different when I checked on the raw json serverside
the testcase itself isn’t stable either.. Right now I have the same consistent hashcode, and it fails because it gets 8 where it expects 9
that bit is a timing problem
when it gets 2 where it expects 1, it’s a hashcode problem
I see my name was mentioned and there are like 100 messages?
so there are two different issues
@ejsmith yeah there were questions for you me and sander and working through them now
@ejsmith do you want me to merge in the EventStats into Foundatio Elasticsearch repository read only base?
O
I’ll merge it in with models cause I need the terms stuff on our repo
ok, my search in .Modules was a stupid move. Conclusion now is that somehow the stacktrace is different
it’s the same stack trace :\
that’s what I don’t get
I get that it could be different in mvc due to maybe a race condition in handlers but crazy
@ejsmith there’s really no good way to do this in the base class:
.WithDateRange(utcStart, utcEnd, EventIndex.Fields.PersistentEvent.Date)
.WithIndices(utcStart, utcEnd, $"'{_eventIndex.VersionedName}-'yyyyMM");
.WithDateRange(utcStart, utcEnd, EventIndex.Fields.PersistentEvent.Date)
.WithIndices(utcStart, utcEnd, $"'{_eventIndex.VersionedName}-'yyyyMM");
getting quantum physics feelings right now
I’m inspecting where it’s probably failing
and it no longer fails
got it
Checking event: with hash: 754157865 1407249123 GetException: 766225261 - ILOffset 8 - NativeOffset87
Checking event: with hash: 752981631 1924808933 GetException: 217121131 - ILOffset 0 - NativeOffset87
Checking event: with hash: 754157865 1407249123 GetException: 766225261 - ILOffset 8 - NativeOffset87
Checking event: with hash: 754157865 1407249123 GetException: 766225261 - ILOffset 8 - NativeOffset87
Checking event: with hash: 754157865 1407249123 GetException: 766225261 - ILOffset 8 - NativeOffset87var error = context.Event.Data["@error"] as Exceptionless.Models.Data.Error;
context.Log.FormattedInfo(typeof(DuplicateCheckerPlugin), String.Concat("Checking event: ", context.Event.Message, " with hash: ", hashCode + " " + error.StackTrace.GetCollectionHashCode() +
" " + string.Join(", ", error.StackTrace.Select(x => x.Name + ": " + x.GetHashCode() + " - ILOffset " + x.Data["ILOffset"] + " - NativeOffset" + x.Data["NativeOffset"]))));
so.. now what?
@niemyjski can you try this change, see if it fixes the real-world problem you were seeing?
hashCode = (hashCode * 397) ^ (Data == null ? 0 : Data.GetCollectionHashCode(new[] { "ILOffset" }));
that code goes in Method
wonder why the iloffset would be different on the same executing code
JIT and pre-JIT or something
C:\Code\Exceptionless.Net\Source\Shared\Models\Client\Data\EnvironmentInfo.cs(131): hashCode = (hashCode 397) ^ (Data == null ? 0 : Data.GetHashCode());
C:\Code\Exceptionless.Net\Source\Shared\Models\Client\Data\InnerError.cs(64): hashCode = (hashCode 397) ^ (Data == null ? 0 : Data.GetHashCode());
C:\Code\Exceptionless.Net\Source\Shared\Models\Client\Data\Method.cs(42): hashCode = (hashCode 397) ^ (Data == null ? 0 : Data.GetCollectionHashCode(new[] { "ILOffset" }));
C:\Code\Exceptionless.Net\Source\Shared\Models\Client\Data\Module.cs(51): hashCode = (hashCode 397) ^ (Data == null ? 0 : Data.GetHashCode());
C:\Code\Exceptionless.Net\Source\Shared\Models\Client\Data\Parameter.cs(36): hashCode = (hashCode 397) ^ (Data == null ? 0 : Data.GetHashCode());
C:\Code\Exceptionless.Net\Source\Shared\Models\Client\Data\RequestInfo.cs(100): hashCode = (hashCode 397) ^ (Data == null ? 0 : Data.GetHashCode());
C:\Code\Exceptionless.Net\Source\Shared\Models\Client\Data\SimpleError.cs(53): hashCode = (hashCode 397) ^ (Data == null ? 0 : Data.GetHashCode());
C:\Code\Exceptionless.Net\Source\Shared\Models\Client\Data\UserDescription.cs(43): hashCode = (hashCode 397) ^ (Data == null ? 0 : Data.GetHashCode());
C:\Code\Exceptionless.Net\Source\Shared\Models\Client\Data\UserInfo.cs(52): hashCode = (hashCode 397) ^ (Data == null ? 0 : Data.GetHashCode());
C:\Code\Exceptionless.Net\Source\Shared\Models\Client\Event.cs(82): hashCode = (hashCode 397) ^ (Data == null ? 0 : Data.GetHashCode());
C:\Code\Exceptionless.Net\Source\Shared\Models\Client\Data\InnerError.cs(64): hashCode = (hashCode 397) ^ (Data == null ? 0 : Data.GetHashCode());
C:\Code\Exceptionless.Net\Source\Shared\Models\Client\Data\Method.cs(42): hashCode = (hashCode 397) ^ (Data == null ? 0 : Data.GetCollectionHashCode(new[] { "ILOffset" }));
C:\Code\Exceptionless.Net\Source\Shared\Models\Client\Data\Module.cs(51): hashCode = (hashCode 397) ^ (Data == null ? 0 : Data.GetHashCode());
C:\Code\Exceptionless.Net\Source\Shared\Models\Client\Data\Parameter.cs(36): hashCode = (hashCode 397) ^ (Data == null ? 0 : Data.GetHashCode());
C:\Code\Exceptionless.Net\Source\Shared\Models\Client\Data\RequestInfo.cs(100): hashCode = (hashCode 397) ^ (Data == null ? 0 : Data.GetHashCode());
C:\Code\Exceptionless.Net\Source\Shared\Models\Client\Data\SimpleError.cs(53): hashCode = (hashCode 397) ^ (Data == null ? 0 : Data.GetHashCode());
C:\Code\Exceptionless.Net\Source\Shared\Models\Client\Data\UserDescription.cs(43): hashCode = (hashCode 397) ^ (Data == null ? 0 : Data.GetHashCode());
C:\Code\Exceptionless.Net\Source\Shared\Models\Client\Data\UserInfo.cs(52): hashCode = (hashCode 397) ^ (Data == null ? 0 : Data.GetHashCode());
C:\Code\Exceptionless.Net\Source\Shared\Models\Client\Event.cs(82): hashCode = (hashCode 397) ^ (Data == null ? 0 : Data.GetHashCode());
should we change all of those to GetCollectionHashCode?
and dump DataDictionary.GetHashCode()
I changed all those to GetCollectionHashCode
“My understanding is that, when provided, the IL offset is simply mapped from the native offset using a table generated at JIT time (which may be an approximation due to optimizations). For the leaf native-frame, the native offset is where the exception was thrown while non-leaf native frames use the return address from the stack which may make it look like the exception was thrown by the instruction following the one where the exception actually happened."
so get rid of the equals and gethashcode overrides in the data
wonderingi f we should leave it as it’s not hurting anything
this dedupe thing?
if you look on the data dictionary we are telling it to ignore tracelogs
complicated stuff
you changed it :D
lol
so basically what we want is ignore
@trace on Error.Data
can add that to an exclusion I guess
and delete that equals code
seems to all be working great!
yeah
first fix this stuff :)
right now I’m checking why we need the locking
they fixed all the issues with mvc!!!
glad I tested before deploying heehe
_processed.Any() is on IEnumerable, so that’s not threadsafe
yeah
for the rest we want ConcurrentDictionary behavior
really wish I could step into these extension methods or go to source but all I see is empty definitions
yep
well I think the issue is that it’s not found in the queue and then other code runs then it enqueues it between checks and the lock prevents that
btw, what’s the difference between FormattedInfo and FormattedTrace?
couldn’t get the Trace to show up in the test runner
oh
LogLevel
and there is a min level in the unit tests of Debug
could update that in GetClient
to get rid of the lock, we would have to keep both a concurrentdictionary (for checking if we have them) and a concurrentqueue (for cleanup of the dictionary)
well if we are locking do we even need concurrentqueue anymore?
it’s not that much harder
@ejsmith this stuff is pretty specific to exceptionless
hitting some roadblocks
stuff like avg:somefield min:somefield, max:somefield
that shouldn’t be specific
but we need access to the elastic index for alias name
can’t do that.
No generic way to inject the index on the context unless we add a constraint to the index with a <T> for the hell of it to auto inject it
then the date stuff is not generic but something we’d have to ahve
that’s only for terms tho
.WithDateRange(utcStart, utcEnd, EventIndex.Fields.PersistentEvent.Date)
.WithIndices(utcStart, utcEnd, $"'{_eventIndex.VersionedName}-'yyyyMM”);
is the biggest thing
you want to do smart date ranges
@niemyjski no ReaderWriterLock in PCL it seems, so just keep the lock the way it is?
that is up to the user to pass in a filter and system filter just like any other thing in the repo
aggregations are on top of that.
wonder if we can get away with non concurrent queues but is it worth it? what might it introduce
ok
yeah good idea :)
@srijken I’m not sure if anything but less chances to dead lock???
between there lock implementations and ours but I don’t see how that would happen with our locks being around everything
see first answer
that kinda suggests that it is in PCL?
oh where’s there’s a bunch of platforms
just leave it
could try a normal queue, and see if the tests + your recent problem are still OK?
is that missing an R in front? ;)
Target Framework Moniker
the stuff where you target an API surface area and all platforms that support that contract or higher just wokr.
and you don’t have to do stuff for each platform
feel free to merge it in
it’s complaining about some reference. How can that be, I just changed one cs file
@srijken you have write access to that repo, do you not see any options to merge?
can you kick that build off once again to see if that does anything?
exceptionless/Exceptionless.Net@85ee49c
can’t see how that can break anything
kicking it off again
been getting those type references for a while
MSBuild version is now 14, last time it succeeded it was at 12
hmm
that’s MSBuild 12
and that’s like yesterday
I updated some dependencies to try and get benchmarks.net to run appears there is an issue with with there latest version
yeah what the hell
C:\Program Files (x86)\MSBuild\14.0\bin\Microsoft.Common.CurrentVersion.targets(1098,5): error MSB3644: The reference assemblies for framework ".NETFramework,Version=v4.5,Profile=Client" were not found. To resolve this, install t
he SDK or Targeting Pack for this framework version or retarget your application to a version of the framework for which you have the SDK or Targeting Pack installed. Note that assemblies will be resolved from the Global Assembly
Cache (GAC) and will be used in place of reference assemblies. Therefore your assembly may not be correctly targeted for the framework you intend.
he SDK or Targeting Pack for this framework version or retarget your application to a version of the framework for which you have the SDK or Targeting Pack installed. Note that assemblies will be resolved from the Global Assembly
Cache (GAC) and will be used in place of reference assemblies. Therefore your assembly may not be correctly targeted for the framework you intend.
but the build you just triggered when you did the hashcode changes on master is also MSBuild 14, and that one doesn’t have this error
I think I broke it
I mean.. this one’s green: https://ci.appveyor.com/project/Exceptionless/exceptionless-net/build/3.4.1648
if you run it again, it should still be green
look at that commit and you can see in 43 that there are compiler related errors for system types
and that’s when the msbuild version changed :(
.Aggregations(agg => BuildAggregations(agg
.Terms("terms", t => BuildTermSort(t
.Field(term)
.Size(max)
.Aggregations(agg2 => BuildAggregations(agg2
.Min("first_occurrence", o => o.Field(ev => ev.Date))
.Max("last_occurrence", o => o.Field(ev => ev.Date)), fields)
), fields)
), fields)
.Terms("terms", t => BuildTermSort(t
.Field(term)
.Size(max)
.Aggregations(agg2 => BuildAggregations(agg2
.Min("first_occurrence", o => o.Field(ev => ev.Date))
.Max("last_occurrence", o => o.Field(ev => ev.Date)), fields)
), fields)
), fields)
with numbers
nope :(
our numbers stats only support numbers and not dates
should be able to do a min and max aggregation on the date.
min:first_occurrence max:last_occurrence
we stick everything in numbers
and those are dates
you mean the results are types as numbers?
and convert them on our end
public async Task<NumbersTimelineStatsResult> GetNumbersTimelineStatsAsync(object query, IEnumerable<FieldAggregation> fields, TimeSpan? displayTimeOffset = null, int desiredDataPoints = 100) {
if (!displayTimeOffset.HasValue)
displayTimeOffset = TimeSpan.Zero;
// if no start date then figure out first event date
if (!filter.DateRanges.First().UseStartDate)
await UpdateFilterStartDateRangesAsync(filter, utcEnd).AnyContext();
utcStart = filter.DateRanges.First().GetStartDate();
utcEnd = filter.DateRanges.First().GetEndDate();
var interval = GetInterval(utcStart, utcEnd, desiredDataPoints);
var response = await Context.ElasticClient.SearchAsync<T>(CreateSearchDescriptor(query)
.SearchType(SearchType.Count)
.Aggregations(agg => BuildAggregations(agg
.DateHistogram("timelime", t => t
.Field(ev => ev.Date)
.MinimumDocumentCount(0)
.Interval(interval.Item1)
.TimeZone(HoursAndMinutes(displayTimeOffset.Value))
.Aggregations(agg2 => BuildAggregations(agg2, fields))
), fields))
.IgnoreUnavailable()
).AnyContext();
yeah that’s going to be fun...
to figure out what field to do the timeline on
guess I need to add a timeline aggregation with a few func’s eh?
side tracked on moving this over cause I need it for what I’m doing with counts per project on the repo
This message was deleted
told me to use previous image
:(
unreal
and it works
so..?
and we weren’t specifying a build image before
otherwise a load of people never upgrade
I agree
there are some issues there that microsoft introduced
and until we drop .net 4.0 or move to standard lib I think they will be there
the build thing, I’d switch back for now, wait what they come up with
and maybe have a branch that doesn’t have that image setting?
pushed*
didn’t merge the PR yet, I’ll see tomorrow what happened ;)
have a good night
var range = (query as IDateRangeQuery)?.DateRanges?.FirstOrDefault();
var interval = GetInterval(range?.GetStartDate() ?? DateTime.MinValue, range?.GetEndDate() ?? DateTime.UtcNow.AddHours(1), desiredDataPoints);
makes me wonder if that should just be a parameter
if you want fine grained intervals you call it
or specify a date range
might be really hard for us to figure out the right interval generically
var range = (query as IDateRangeQuery)?.DateRanges?.FirstOrDefault();
if (range == null || !range.UseDateRange)
throw new ArgumentOutOfRangeException(nameof(query), "Query must contain a valid date range.");
var interval = GetInterval(range.GetStartDate(), range.GetEndDate(), desiredDataPoints);
DateRange has a field property that we can use
but UseDateRange will return false if the start date is not greater than DateTime.MinValue so what if you want a range of all time?
wonder if well have issues with unlimited plans..
let me know if you want to look at this with me later