Issue #1428: exception when parsing timestamp

[jbennett2091]

Fixes #1428
If parsing fails, use default timestamp instead

[codecov]

Codecov Report

Merging #1429 (a3a96fd) into master (e7fefda) will increase coverage by 0.05%.
The diff coverage is 100.00%.

@@             Coverage Diff              @@
##             master    #1429      +/-   ##
============================================
+ Coverage     57.69%   57.75%   +0.05%     
- Complexity     1916     1917       +1     
============================================
  Files           161      161              
  Lines          9006     9009       +3     
  Branches       1359     1359              
============================================
+ Hits           5196     5203       +7     
+ Misses         3335     3332       -3     
+ Partials        475      474       -1     

Impacted Files	Coverage Δ	Complexity Δ
.../fabric8/maven/docker/access/log/LogRequestor.java	84.52% <100.00%> (+5.51%)	14.00 <0.00> (+1.00)

[jbennett2091]

Fixes #1428

[jbennett2091]

squashed and signed-off

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

100.0% Coverage
0.0% Duplication

[rhuss]

Thanks for the fix (and sorry for the delay) but I think we should also check, which the extraction of the timestamp fails in the first place. Happy to add a fallback (not sure about using the current timestamp though as there can be a considerable drift between the local time and the server time), but I suspect that the log line that causes the error matched the LOG_LINE regexp, but in an undesired way (i.e. the output of the log might have changed).

Could you check what concrete log line caused the error? Maybe the regexp could be adapt to pick up the concrete value. (btw the "Error" part in the exception provided in the original issue also looks a bit suspicious)

[jbennett2091]

Hi Roland- I made a cursory attempt at the time to determine the log-line that generated the issue, but was never able to pin it down precisely - lots of spam and a messy business process.  I am no longer at this gig, so ability to recheck it at this point is not possible for me.  I do know the fix provided "worked for me" - seemed to turn a hard-exception into code-that-runs. On Sunday, March 7, 2021, 04:57:00 AM EST, Roland Huß <[email protected]> wrote: Thanks for the fix (and sorry for the delay) but I think we should also check, which the extraction of the timestamp fails in the first place. Happy to add a fallback (not sure about using the current timestamp though as there can be a considerable drift between the local time and the server time), but I suspect that the log line that causes the error matched the LOG_LINE regexp, but in an undesired way (i.e. the output of the log might have changed). Could you check what concrete log line caused the error? Maybe the regexp could be adapt to pick up the concrete value. (btw the "Error" part in the exception provided in the original issue also looks a bit suspicious) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[rhuss]

yeah, no worries. I think we can more or less apply this fix but also log out a warning with the full log line in case we hit this. So hopefully we can fine tune the regexp in retrospective then.

[rhuss]

Sorry, there are conflict, not sure how to resolve those (it's very likely JMockit vs. Mockito ...)