Retry-After parser accepts invalid delay-seconds values
Maintainers usually reply within 2 days
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 82/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- java
- Domain
- backend-api-design
Research direction
Start with RetryUtil.retryAfterNanos and its existing tests in io.opentelemetry.exporter.internal.RetryUtilTest. Check how the parser handles +30, -0, and ٣٠, then run that test class. Done means each malformed value returns OptionalLong.empty() while valid ASCII delay-seconds values continue to parse.
Written by the indexing model from the issue text.
Description
Describe the bug
The internal RetryUtil.retryAfterNanos parser accepts +30 as a 30-second delay and -0 as zero. Long.parseLong also accepts non-ASCII decimal digits. These values do not match the HTTP Retry-After delay-seconds grammar (1*DIGIT, ASCII 0–9).
The JDK and OkHttp HTTP senders use this parser. An accepted malformed value overrides their ordinary retry backoff instead of being ignored.
Steps to reproduce
In the existing io.opentelemetry.exporter.internal.RetryUtilTest, pass +30, -0, or ٣٠ to RetryUtil.retryAfterNanos(value, Instant.EPOCH).
What did you expect to see?
OptionalLong.empty(), as for other malformed values, so the ordinary retry policy applies.
What did you see instead?
OptionalLong.of(30000000000L) for +30; OptionalLong.of(0L) for -0; non-ASCII decimal digits are also parsed as a delay.
What version and what artifacts are you using?
Artifacts: exporters/common (used by the JDK and OkHttp senders)
Version: source checkout at f02bddc
How referenced: direct source checkout
Environment
Compiler: Temurin 25.0.5
OS: macOS 15.5
Additional context
The HTTP grammar is defined in RFC 9110 section 10.2.3.
- Dominant language
- Java
- Stars
- 2.5k
- Forks
- 1k
- Avg merge
- 4d 3h
- Merged PRs (30d)
- 49
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from open-telemetry/opentelemetry-java
-
PrometheusComponentProvider promotes all resource attributes when resource_constant_labels is empty ({})Possibly taken @rooks-ns claimed this 1 day ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
open-telemetry/opentelemetry-java#9014 ·
Maintainers usually reply within 2 days
-
MetricReusableDataMarshaler passes MetricData count instead of data point count to otel.sdk.exporter.metric_data_point.{inflight,exported}Possibly taken @goutamadwant claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
open-telemetry/opentelemetry-java#9011 · 1 comment ·
Maintainers usually reply within 2 days
-
Fix `otel.sdk.log.created` counting semanticsPossibly taken @anuraaga claimed this 94 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
open-telemetry/opentelemetry-java#8688 ·
Maintainers usually reply within 2 days
-
Add experimental view_matching_mode (composable metric views) supportPossibly taken @rooks-ns claimed this today. Open
Difficulty 5/5 Over a week Newbie friendliness 35/100
open-telemetry/opentelemetry-java#9013 ·
Maintainers usually reply within 2 days
-
Span/log processors and PeriodicMetricReader use static ComponentId, causing all instances to share otel.component.name "<type>/0"Possibly taken @goutamadwant claimed this today. Open
Difficulty 3/5 1-2 days Newbie friendliness 68/100
open-telemetry/opentelemetry-java#9012 ·
Maintainers usually reply within 2 days
All issues in open-telemetry/opentelemetry-java
Similar issues
-
Document and enforce pull request review guidelinesPossibly taken @dashorst claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day
-
`Time.at(t, in: nil)` returns UTC instead of the local time (or the time zone of `t`), unlike CRubyOpen
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
hermes-queue
Difficulty 1/5 Under an hour Newbie friendliness 72/100
chrisalunlloyd2-sudo/mindpalace#349 ·
Maintainers usually reply within 1 day
-
bug priority: medium Review effort [1-5]: 2 status: needs-triage type: bug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
carlos-emr/carlos#5818 ·
Maintainers usually reply within 1 day
-
bug good first issue help wanted tooling
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
appmonster007/kmip-adapter#100 ·