Repository navigation
[DSM] Fix RabbitMQ time in queue treating AMQP timestamp seconds as milliseconds - #9455
Conversation
…stamps in seconds A consumed RabbitMQ message with no upstream DSM context back-dates its edge start by the AMQP timestamp property. AMQP 0-9-1 defines that property as POSIX seconds, but the integration subtracts it from a millisecond clock, so the edge and pathway start land near 1970-01-21 (about 55 years of latency). Covers both BasicDeliver and BasicGet, and pins the current behaviour for publishers that write milliseconds. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…ing DSM time in queue AMQP 0-9-1 and RabbitMQ.Client store the timestamp property as POSIX seconds, but BasicDeliver and BasicGet subtracted it from a millisecond clock. For consumes with no upstream DSM context this back-dated the edge and pathway start to around 1970-01-21, reporting about 55 years of latency. Both call sites now go through RabbitMQIntegration.GetTimeInQueueMs, which treats values below 1e11 as seconds and larger values as milliseconds, so publishers that already write milliseconds keep the current behaviour. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
BenchmarksBenchmark execution time: 2026-10-27 15:41:44 Comparing candidate commit 6971b03 in PR branch Found 0 performance improvements and 0 performance regressions! Performance is the same for 71 metrics, 1 unstable metrics, 12 known flaky benchmarks, 114 flaky benchmarks without significant changes.
|
ReadOnlyMemory<T> is ambiguous on netcoreapp2.1 and .NET Framework test targets because Datadog.Trace vendors System.Memory and exposes its internals to the test assembly (CS0433). IBody only needs Length, so a plain class stands in for the message body. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Execution-Time Benchmarks Report ⏱️Execution-time results for samples comparing This PR (9455) and master. ✅ No regressions detected |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
There was a problem hiding this comment.
More details
The timestamp conversion covers synchronous and asynchronous RabbitMQ consumers while preserving existing millisecond timestamps. Runtime validation remains limited by the unavailable .NET 11 RC SDK.
🤖 Bits Code Review · Commit d739ee5
|
/azp run |
|
/merge |
|
View all feedbacks in Devflow UI.
The merge queue is disabled for this repository/branch. |
andrewlock
left a comment
There was a problem hiding this comment.
The fix LGTM, thanks (with a tiny nit), but the test is much too heavy weight IMO. We could add a simple unit test and that would be sufficient I think
…it test Tests RabbitMQIntegration.GetTimeInQueueMs directly instead of driving BasicDeliver through the global Tracer, so the test is parallel-safe and needs no TracerRestorer, fake spans or message bodies. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Thanks @andrewlock, swapped the test for a small unit test and applied the nit. LMK if anything else |
andrewlock
left a comment
There was a problem hiding this comment.
Thanks! Though the nit was slightly off - if my suggestion doesn't work for some reason, then your previous code was preferable to the latest 😄
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Summary of changes
Convert the AMQP
timestampfrom seconds to milliseconds before computing RabbitMQ DSM time in queue.Reason for change
AMQP and RabbitMQ.Client store
BasicProperties.Timestampin seconds, butBasicDeliverandBasicGetsubtracted it from a millisecond clock. For consumed messages without DSM context, pathway latency read about 57 years. Present since v2.37.0.Implementation details
New
RabbitMQIntegration.GetTimeInQueueMs, used by both consume paths. Values below 1e11 are treated as seconds; larger values (publishers writing ms) behave as before. Future timestamps clamp to 0.Test coverage
Unit tests for
GetTimeInQueueMs(zero, seconds, milliseconds, future).🤖 Generated with Claude Code