Skip to content

feat(ads-client): retry callback requests once on transient transport failure#7361

Draft
Almaju wants to merge 1 commit into
mozilla:mainfrom
Almaju:ads-client-callback-retry
Draft

feat(ads-client): retry callback requests once on transient transport failure#7361
Almaju wants to merge 1 commit into
mozilla:mainfrom
Almaju:ads-client-callback-retry

Conversation

@Almaju
Copy link
Copy Markdown
Contributor

@Almaju Almaju commented May 11, 2026

Summary

recordImpression, recordClick, and reportAd are fire-and-forget calls — once a consumer hands them off, they have no easy way to know whether to retry. On flaky mobile networks (timeouts, brief connection resets, DNS hiccups), a single transport-level failure currently drops the callback silently.

This adds a single retry, 500ms after the first attempt, when viaduct::ViaductError is returned. HTTP status errors (4xx/5xx) are not retried — those are application decisions, not transient blips.

The retry policy is a small free function (retry_once) so the behaviour is unit-testable without faking a viaduct backend.

Pull Request checklist

  • Breaking changes: This PR follows our breaking change policy
    • This PR follows the breaking change policy:
      • This PR has no breaking API changes, or
      • There are corresponding PRs for our consumer applications that resolve the breaking changes and have been approved
  • Quality: This PR builds and tests run cleanly
    • Note:
      • For changes that need extra cross-platform testing, consider adding [ci full] to the PR title.
      • If this pull request includes a breaking change, consider cutting a new release after merging.
  • Tests: This PR includes thorough tests or an explanation of why it does not
  • Changelog: This PR includes a changelog entry in CHANGELOG.md or an explanation of why it does not need one
    • Any breaking changes to Swift or Kotlin binding APIs are noted explicitly
  • Dependencies: This PR follows our dependency management guidelines
    • Any new dependencies are accompanied by a summary of the due diligence applied in selecting them.

… failure

`recordImpression`, `recordClick`, and `reportAd` are fire-and-forget
calls that consumers can't easily redo. On unreliable mobile networks
they were silently lost on a single timeout, connection reset, or DNS
hiccup. Retry the request once after a 500ms wait when viaduct
reports a transport-level error.

HTTP status errors are intentionally not retried — those are application
decisions, not transient blips.

Extracted as a small `retry_once` helper so the retry policy is testable
without needing to fake a viaduct backend.
@Almaju Almaju marked this pull request as draft May 12, 2026 20:17
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.

1 participant