* Add advance_datum and advance_event_time to nimbus_client.
* Tidy out Utc::now from event_store
* Add API to advance_event_time
* Add Android API + tests
* Add iOS API + tests
* Add changelog
* Address reviewer comment
Use the serde_path_to_error crate to get the path where an error occured
when deserializing BSOs. I hope this will help with things like
`Invalid incoming T: invalid type: null, expected a string` (#5457). I
also think the error path is just generally useful.
I couldn't figure out a good test for this, but I did some manually
checking and the paths seem correct to me.
* Add Rust to look up the experiment/rollout per feature
* Add metric declaration for malformedFeature
* Add Swift to record exposure and malformed configuration
* Add Kotlin to record exposure and malformed configuration
* Add changelog
* Add link to data-review+
Added a new crate called `rust-log-forwarder` that forwards logs to
consumers. This does basically the same thing as `rc-log`, but it uses
UniFFI. Once our consumer apps swich over to `rust-log-forwarder`, we
can remove the `rc-log` component.
- Renamed `PlacesInternalError` to `Error` because it seems more
idiomatic
- Renamed `PlacesError` to `PlacesApiError` to make it consistent with
the logins errors. I considered just calling this `ApiError` but I
thought that would be confusing for consumers since they won't always
have the `places::` prefix before the class name.
- Removed `JsonError`, which seems like it was unusped
- Merged `InternalError` into `UnexpectedPlacesException`
- Merged `UrlTooLong` into `UrlParseFailed` for `PlacesApiError`
- Merged `InvalidBookmarkUpdate`, `CannotUpdateRoot`, `InvalidParent`
into `InvalidBookmarkOperation` for `PlacesApiError`
Use the fielded style for `PlacesApiError` in places.udl. Updated
`PlacesApiError` to use named fields to be compatible with this.
On swift renamed `PlacesApiError`, which was defined on top of the
normal errors to `PlacesConnectionError`.
If the new feature is enabled, tabs can sync - otherwise it can not.
The intention is that later there will be a "bridged-sync" feature,
and that in-practice, one or the other will be enabled - however, the
way features work, it must be possible that no features are enabled.
The new feature is not a default feature because I expect we will
want the default features to be what desktop consumes - ie, that
the default feature will be bridged-sync once that exists.
This isn't strictly required yet, but is being done now to make
future reviews of the bridged engine easier to reason about.
This now uses Glean directly through the org.mozilla.telemetry:glean
package, instead of its Android Components release.
This is required to avoid a dependency cycle:
* The migration component in a-c requires Glean and a-s
* a-s requires Glean from a-c
But there can only be one Glean in the build.
So in order to not need to release individual components manually we
switch a-s to directly consume Glean.
Then we can update a-s and get that into a-c together with a Glean
update there.
I'm hoping that this can replace the current system where `rc_log`
forwards the logging calls, then we report the `log::error` messages to
Sentry. Instead, let's use something more explicit and with more
options.
- The general system allows for:
- Error reports that get sent to Sentry
- Error counts that get sent to Glean
- Error breadcrumbs
- Added the `ApplicationErrorReporter` trait. Fenix, iOS, Desktop, or
whatever application is consuming us can implement this trait and
set the global error reporter object. It will then see the error
reports, breadcrumbs, etc.
- Added error reporting macros that components can use to send errors
to the currently installed `ApplicationErrorReporter`.
- Breadcrumbs store the module/line/column where they were logged. I'm
hoping this can help make up for the lack of backtrace support. In
particular, the `trace_error()!` macro can be used to log a breadcrumb
when a function returns an error.
- UniFFI'ed the error-support crate and added it to the megazord.
- Use an explicit cast rather than `into()` in `pk11/types.rs`. I'm not
sure exactly why, but changing the dependencies made it so there were
now multiple `Into` implementations available and the compiler
complained.
Charlie
Mark Hammond
jhugman
lougeniaC64
Ben Dean-Kawamura
Travis Long
Ryan VanderMeulen
Tarik Eshaq
Jan-Erik Rediger
Jan-Erik Rediger