Skip to content

TE: Fixing time interval for baseline based analysis#524

Merged
puneetjaiswal merged 2 commits intomasterfrom
te_baseline_time_interval_fix
Sep 9, 2016
Merged

TE: Fixing time interval for baseline based analysis#524
puneetjaiswal merged 2 commits intomasterfrom
te_baseline_time_interval_fix

Conversation

@puneetjaiswal
Copy link
Contributor

@puneetjaiswal puneetjaiswal commented Sep 9, 2016

Fixing time interval for baseline based analysis

}

public List<Pair<Long, Long>> getDataRangeIntervals(Long scheduleStartTime,
Long scheduleEndTime) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is actually windowStart/EndTime

@kishoreg
Copy link
Member

kishoreg commented Sep 9, 2016

LGTM. Thanks for fixing it the right way

@puneetjaiswal puneetjaiswal merged commit 7c76e6f into master Sep 9, 2016
@puneetjaiswal puneetjaiswal deleted the te_baseline_time_interval_fix branch September 9, 2016 22:25
timothy-e pushed a commit to timothy-e/pinot that referenced this pull request Feb 23, 2026
…stamps (long.min for example) (apache#524)

### Notify
cc stripe-private-oss-forks/pinot-reviewers

### Summary
When `ingestionInfo` is null or `firstStreamIngestionTimeMs` is negative (e.g., `Long.MIN_VALUE`), the method incorrectly computed `clock.millis() - 0`, returning ~1.7 trillion ms instead of 0 and e2e lag showing as ~56 years (1970).

This fix adds an early return of 0 for invalid/missing timestamps, restoring the original behavior from upstream commit [bea67d04](apache@bea67d04).

I'm going to OSS this also, but for the sake of not slowing down pinot 1.5; need to get this in here faster

investigated more in https://docs.google.com/document/d/19EUPSq2xjEBiGHynGgZmTMZOIB7zmm2FwdzdC8FjqHg/edit?tab=t.0

but after deployment in rad-canary, we can see the fix in action:
![image](https://git.corp.stripe.com/user-attachments/assets/f60b44d9-4379-42a0-8cb0-a359c6276b86)

i've made it show the dedup table doesnt use the header, but the non-dedup ones do, and our upstream code sets a value of 1 hour ago, hence the 1 hour lag being shown

we don't see the 56 years anymore prior:
![image](https://git.corp.stripe.com/user-attachments/assets/b0db590b-d1b3-4033-b54e-68290aa2ee3c)



### Motivation
https://jira.corp.stripe.com/browse/STREAMANALYTICS-4191

### Testing
deployed on rad-canary QA and metric looks correct now

also updated tests
```
```
$ mvn test -pl pinot-core -Dtest=IngestionDelayTrackerTest -DfailIfNoTests=false

[INFO] Running org.apache.pinot.core.data.manager.realtime.IngestionDelayTrackerTest
[INFO] Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.797 s -- in org.apache.pinot.core.data.manager.realtime.IngestionDelayTrackerTest
[INFO] org.apache.pinot.core.data.manager.realtime.IngestionDelayTrackerTest.testIngestionDelay -- Time elapsed: 0.147 s
[INFO] org.apache.pinot.core.data.manager.realtime.IngestionDelayTrackerTest.testRecordIngestionDelayOffset -- Time elapsed: 0 s
[INFO] org.apache.pinot.core.data.manager.realtime.IngestionDelayTrackerTest.testRecordIngestionDelayWithAging -- Time elapsed: 0 s
[INFO] org.apache.pinot.core.data.manager.realtime.IngestionDelayTrackerTest.testRecordIngestionDelayWithNoAging -- Time elapsed: 0.016 s
[INFO] org.apache.pinot.core.data.manager.realtime.IngestionDelayTrackerTest.testShutdown -- Time elapsed: 0.003 s
[INFO] org.apache.pinot.core.data.manager.realtime.IngestionDelayTrackerTest.testStopTrackingIngestionDelay -- Time elapsed: 0.003 s
[INFO] org.apache.pinot.core.data.manager.realtime.IngestionDelayTrackerTest.testStopTrackingIngestionDelayWithSegment -- Time elapsed: 0.003 s
[INFO] org.apache.pinot.core.data.manager.realtime.IngestionDelayTrackerTest.testTrackerConstructors -- Time elapsed: 0.001 s
[INFO] org.apache.pinot.core.data.manager.realtime.IngestionDelayTrackerTest.testUpdateLatestStreamOffset -- Time elapsed: 0.003 s
[INFO] Tests run: 9, Failures: 0, Errors: 0, Skipped: 0
[INFO] BUILD SUCCESS
```
```

### Rollout/monitoring/revert plan
s:pinot-rad-canary


Stripe-Original-Repo: stripe-private-oss-forks/pinot
Stripe-Monotonic-Timestamp: v2/2026-01-30T21:51:39Z/0
Stripe-Original-PR: https://git.corp.stripe.com/stripe-private-oss-forks/pinot/pull/524
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants