azure-webjobs-sdk icon indicating copy to clipboard operation
azure-webjobs-sdk copied to clipboard

FunctionResultAggregatorTests fail east of Greenwich

Open pjt33 opened this issue 2 years ago • 0 comments

FunctionResultAggregatorTests succeed or fail depending on the local timezone. They should be independent of the timezone.

Repro steps

  1. Configure your computer to UTC+1.
  2. Run the unit tests.

Expected behavior

FunctionResultAggregatorTests should pass.

Actual behavior

Microsoft.Azure.WebJobs.Host.UnitTests.Loggers.FunctionResultAggregatorTests.Aggregator_AlternatesTimerAndBatch
  Source: FunctionResultAggregatorTests.cs line 65
  Duration: 1.3 sec

Message: 
  Assert.Equal() Failure
  Expected: 3
  Actual:   0

Stack Trace: 
  FunctionResultAggregatorTests.Aggregator_AlternatesTimerAndBatch() line 86
  --- End of stack trace from previous location where exception was thrown ---

and similarly Aggregator_Flushes_WhenTimerFires and the two sub-tests of Aggregator_Flushes_WhenBatchIsFull.

The root cause is concealed by the asynchronous processing: it's an exception thrown from FunctionResultAggregator.Aggregate because all of the events logged by the test have StartTime left at default(DateTime). This can be implicitly converted to a DateTimeOffset (FunctionResultAggregate.Timestamp) in UTC and timezones to the west of it, but in timezones to the east it produces a negative year.

Known workarounds

The quick and easy way to get the tests to actually test what they're supposed to be testing is to set StartTime = DateTime.Now in the relevant FunctionInstanceLogEntry instance in FunctionResultAggregatorTests.AddSuccessResults. But I wonder whether the correct fix would not be to add a sanity check

if (result.StartTime == default)
{
    throw new ArgumentException(nameof(result));
}

to FunctionResultAggregator.AddAsync

Related information

Problem dates back a while, but is still present in e210142b674d1324fbbe49ffe5767f834e15c719 (currently dev).

pjt33 avatar Feb 15 '23 17:02 pjt33