viiccwen opened a new issue, #69970:
URL: https://github.com/apache/airflow/issues/69970

   ### Under which category would you file this issue?
   
   Airflow Core
   
   ### Apache Airflow version
   
   `main`
   
   ### What happened and how to reproduce it?
   
   The `triggerer.trigger_queue_delay` metric measures the duration between the 
TriggerRunnerSupervisor queueing a trigger workload and the TriggerRunner 
creating the trigger. Both timestamps currently use `time.time()`.
   
   If NTP, virtualization, or an administrator adjusts the system clock between 
those operations, the metric can become negative or be inflated even though the 
actual queue delay is normal.
   
   Minimal reproduction:
   
   1. Create a trigger workload with `queued_at=100.0`.
   2. Simulate the wall clock moving backward so that `time.time()` returns 
`90.0` when the TriggerRunner creates the trigger.
   3. Observe that the emitted queue delay is `-10000` milliseconds.
   
   This can also be reproduced in the existing 
`test_create_triggers_emits_queue_delay_metric` test by setting the workload's 
queue timestamp to `100.0`, mocking `time.time()` to return `90.0`, and 
expecting the real elapsed delay from a stable clock.
   
   ### What you think should happen instead?
   
   Queue delay is a duration and should use `time.monotonic()` at both the 
producer and consumer ends. System wall-clock  djustments should not affect the 
emitted metric.
   
   ### Operating System
   
   _No response_
   
   ### Deployment
   
   None
   
   ### Apache Airflow Provider(s)
   
   _No response_
   
   ### Versions of Apache Airflow Providers
   
   _No response_
   
   ### Official Helm Chart version
   
   Not Applicable
   
   ### Kubernetes Version
   
   _No response_
   
   ### Helm Chart configuration
   
   _No response_
   
   ### Docker Image customizations
   
   _No response_
   
   ### Anything else?
   
   The metric was introduced by #67927. A tested fix is ready that changes both 
timestamp sites to `time.monotonic()` and adds regression coverage for a 
backward wall-clock adjustment.
   
   ### Are you willing to submit PR?
   
   - [x] Yes I am willing to submit a PR!
   
   ### Code of Conduct
   
   - [x] I agree to follow this project's [Code of 
Conduct](https://github.com/apache/airflow/blob/main/CODE_OF_CONDUCT.md)
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to