* 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.
James Hugman
Charlie
Tarik Eshaq
MatthewTighe
Mark Hammond
jhugman
lougeniaC64
Ben Dean-Kawamura
Travis Long
Ryan VanderMeulen
Jan-Erik Rediger
Jan-Erik Rediger