gecko-dev/python
Ricky Stewart e1e9ea0e63 Bug 1645423 - Sentry ignores errors caused by local changes r=mhentges
Here, "errors caused by local changes" means "errors whose stack traces contain a reference to a file that is in the set of files changed locally". This implementation is a trade-off:

1. This check will not catch issues caused transitively by changes to local files. For example, consider a function that has been updated and its return type changed in a backwards-incompatible way, whereas callers were not updated appropriately. This would likely manifest as a type error in the calling function after the callee has returned.

2. This check WILL catch issues that come from locally changed files where the cause of the error doesn't originate from those local changes. For example, consider a function that's been locally updated but is never called in the failing codepath; if an exception is thrown, it's not due to this local change, and we shouldn't filter it out.

There are conceivable improvements that we could apply to fix deficiency (1); for example, we could track imports recursively starting from the oldest frame in the stack trace and match on that set of imported files. Note this would not handle dynamic imports properly, and that this could exacerbate issue (2).

Issue (2) could conceivably be addressed by attempting to filter the actual local diffs down to changes that actually may be causing the error. This is difficult to do generally especially in light of Python's dynamism, but there mayb be conservative improvements that we could make in this space.

Overall, neither of the above caveats are deemed to be sufficiently concerning that this patch should be blocked as-is, and the current situation with our Sentry logs is unusable due to all the noise. This patch will probably have a substantial impact on that noise without incidentally filtering out too much signal.

Differential Revision: https://phabricator.services.mozilla.com/D95607
2020-11-03 19:22:51 +00:00
..
devtools/migrate-l10n Bug 1654103: Standardize on Black for Python code in `mozilla-central`. 2020-10-26 18:34:53 +00:00
docs
gdbpp/gdbpp Bug 1654103: Standardize on Black for Python code in `mozilla-central`. 2020-10-26 18:34:53 +00:00
l10n Bug 1565574 - Migrate protocol handler dialog strings to fluent. r=Gijs,flod 2020-10-29 13:44:01 +00:00
lldbutils Bug 1654103: Standardize on Black for Python code in `mozilla-central`. 2020-10-26 18:34:53 +00:00
mach Bug 1645423 - Sentry ignores errors caused by local changes r=mhentges 2020-11-03 19:22:51 +00:00
mozboot Bug 1674189 - Warn the user if their PYTHONPATH is set in mach bootstrap; r=rstewart DONTBUILD 2020-10-30 09:28:05 +00:00
mozbuild Bug 1674398 - Follow-up: Correct base path and pattern for comm mozharness.zip. r=ahal 2020-11-03 18:15:36 +00:00
mozlint Bug 1673874 - [mozlint] Add some verbose logging after calling a linter's setup function, r=gregtatum 2020-10-28 22:02:07 +00:00
mozperftest Bug 1671330 - create a telemetry layer r=sparky 2020-11-03 14:32:33 +00:00
mozrelease Bug 1654103: Standardize on Black for Python code in `mozilla-central`. 2020-10-26 18:34:53 +00:00
mozterm Bug 1654103: Standardize on Black for Python code in `mozilla-central`. 2020-10-26 18:34:53 +00:00
mozversioncontrol Bug 1654103: Standardize on Black for Python code in `mozilla-central`. 2020-10-26 18:34:53 +00:00
README
mach_commands.py Bug 1654103: Standardize on Black for Python code in `mozilla-central`. 2020-10-26 18:34:53 +00:00
moz.build Bug 1654103: Standardize on Black for Python code in `mozilla-central`. 2020-10-26 18:34:53 +00:00

README

This directory contains common Python code.

The basic rule is that if Python code is cross-module (that's "module" in the
Mozilla meaning - as in "module ownership") and is MPL-compatible, it should
go here.

What should not go here:

* Vendored python modules (use third_party/python instead)
* Python that is not MPL-compatible (see other-licenses/)
* Python that has good reason to remain close to its "owning" (Mozilla)
  module (e.g. it is only being consumed from there).

Historical information can be found at
https://bugzilla.mozilla.org/show_bug.cgi?id=775243
https://bugzilla.mozilla.org/show_bug.cgi?id=1346025