Llucs commented on PR #42361: URL: https://github.com/apache/superset/pull/42361#issuecomment-5151634918
> Appreciate the disclosure, @Llucs. The thing I'm stuck on is the tradeoff: `backoff` is archived but stable and already zero-dep, so this swaps a battle-tested dep for a newer one with a single maintainer. What's the concrete win that offsets that? If `backoff` is actually leaving us with a real gap, that'd change my opinion. Thanks @rusackas — that's exactly the right question to ask, and I'd rather make the case concrete than vibes-based. **Is `backoff` actually leaving a gap? Yes, and it's already visible:** 1. **Python 3.14+ compatibility.** `backoff`'s async module uses `asyncio.iscoroutinefunction`, which is deprecated in Python 3.14 (litl/backoff#220). The fix was written, but the repo was archived immediately after (last release `v2.2.1` in Oct 2022, last commit May 2024), so it will never ship to PyPI. Superset uses backoff precisely in its async code paths — `reports/notifications/slack.py`, `slackv2.py`, `webhook.py` — so anyone running on 3.14 gets the deprecation warning today, and when 3.14 deprecations are removed in 3.15, `@rusackas ff.on_exception` on async functions breaks at runtime. That's the concrete gap: this is not hypothetical, it's already mid-transition. 2. **Zero maintenance = zero security response.** "Stable" here really means "frozen". Archived means no releases, no CVE fixes, no reply. If a vulnerability is ever found in its retry logic or its deps, Superset can't get a patched version — it would have to vendor or fork internally. With backon, fixes ship (4.4.4 went out today, and the project has 100+ commits in 2026 alone). 3. **The cost of the current dep is not zero either:** the fix for the 3.14 issue sits unreleased in the archived repo, and issues are closed without action. That's deferred cost that lands on Superset's maintainers the moment Python versions move. **On the single-maintainer concern — fair, let me address it head-on:** - The bus factor of `backoff` while it was alive was effectively the same — a tiny project maintained by one or two people. The difference is: when backon loses its maintainer, it's not an archived dead end, and the repo is open for anyone to fork/continue. - The swap is trivially reversible: it's a drop-in API (`on_exception`/`expo`/`constant`), the diff is ~8 files, and reverting is a one-line requirement change plus an import rename. - Practical mitigations I'm happy to do right in this PR: pin `backon` to an exact version, and I'll add a security policy + co-maintainers on backon if that helps reduce the bus-factor risk. So the tradeoff as I see it: swap a dependency that's been frozen since before Python 3.13 stabilized, for a zero-dep, drop-in equivalent that actively follows Python releases — at the cost of a smaller track record, which the pin + review process can mitigate. If `backoff` staying frozen is genuinely fine for Superset's roadmap, I fully respect that call — but the gap (3.14/3.15 + no security path) is real and only grows over time. -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
