{"task": {"agent_timeout": 3000, "task": "testgen__jaegertracing__jaeger-6566", "verifier_timeout": 3000, "instruction": "The following text contains a user issue (in <issue/> brackets) posted at a repository. Further, you are provided with file contents of several files in the repository that contain relevant code (in <code> brackets). It may be necessary to use code from third party dependencies or files not contained in the attached documents however. Your task is to identify the issue and implement a test case that verifies a proposed solution to this issue. More details at the end of this text.\n<issue>\n      ### What happened?\n\nI'm having a distributed tracing setup in which some devices have a clock difference of several seconds and wanted to adjust the maximum clock skew adjustment duration.\n\nAfter some digging into the config structures, I found that the yaml setting should be as follows and confirmed it's parsed and accepted by the server, as it errors on any unknown config field:\n\n```yaml\nextensions:\n  jaeger_query:\n    max_clock_skew_adjust: 5s\n```\n\nThis is the equivalent of the `--query.max-clock-skew-adjustment=5s` of Jaeger v1.\n\nHowever, it seems this setting is not being applied in v2 at all, as regardless of what duration is set, it always applies the default of 1 second.\n\n### Steps to reproduce\n\n1. Have a Jaeger instance and two OTLP clients set up with different clock timing.\n  1.1. The clients should have a clock difference of at least a few seconds.\n  1.2. The clients must be setup for distributed tracing so their traces are combined in Jaeger.\n3. Configure Jaeger to accept larger durations that 1 second.\n4. View a trace in the UI that is a distributed trace of both clients.\n5. Verify that the spans of the clients are far apart and not normalized, despite the configured max clock skew adjustment. A warning will be shown in the spans, saying that the clock skew exceeds the limit.\n\n### Expected behavior\n\nThe Jaeger server should apply the max clock skew adjustment setting accordingly.\n\n### Relevant log output\n\n```shell\n\n```\n\n### Screenshot\n\n_No response_\n\n### Additional context\n\n_No response_\n\n### Jaeger backend version\n\nv2.2.0\n\n### SDK\n\nRust setup with `tracing`, `tracing-subscriber`, `tracing-opentelemetry` and various crates from the [opentelemetry-rust](https://github.com/open-telemetry/opentelemetry-rust) project.\n\nAll with the latest version as of writing, but this appears to be no client-side error anyway.\n\n### Pipeline\n\nOTEL SDK -> [OTLP] -> Jaeger v2\n\nSame pipeline for 2 clients, but the clients are on different installments:\n- Server system receiving requests.\n- Android app sending requests.\n\nIn a local setup the server is run in Docker, and the app is run in an Android emulator.\n\n### Stogage backend\n\nBadger\n\n### Operating system\n\nLinux\n\n### Deployment model\n\nDocker Compose\n\n### Deployment configs\n\n```shell\n\n```\n\n</issue>\nPlease generate test cases that check whether an implemented solution resolves the issue of the user (at the top, within <issue/> brackets).\nYou may apply changes to several files.\nApply as much reasoning as you please and see necessary.\nMake sure to implement only test cases and don't try to fix the issue itself.\nYou are not allowed to read git history.\n", "memory": "8192m", "runnable": false, "difficulty": "hard", "language": "", "cpus": "", "instruction_truncated": false, "category": "test-generation", "compose": false, "has_solution": true, "oracle": null, "docker_image": "", "taskset": "devopsgym", "tags": ["test-generation", "devops-bench"]}, "runs": []}