* Add test to demonstrate hang when attempting to init while waiting for a patch check request
* Fix thread contention when initing during patch check
* Clean up test
* revert change to fake_yaml
* reorg
* lower timeout in test
* fix: verify failed patch is next_boot_patch before clearing
* add record_boot_start_for_patch now that it exists
* fix: delete all old patch artifacts on successful boot
* add comment
* additional docs on delete_patch_artifacts_older_than
* update comments
* delete unrecognized patch subdirectories
* error logging
* fix: verify failed patch is next_boot_patch before clearing
* add record_boot_start_for_patch now that it exists
* add comment
* add comments
* cleanup
We added client_id back when we had a different billing model
where we would bill customers based on number of unique devices
accepting an install in a given month (similar to what expo.dev
advertised as their pricing model at the time).
We moved to a differnet pricing model and never used client_id
so removing it.
I just ran `cargo clippy -- -W clippy::pedantic` and fixed things.
These are more invasive that the default set and the remaining
warnings are mostly about our (abysmal) public docs missing
Error and Panic sections to explain errors and panicks.
* feat: report failure events to our servers
This doesn't tell us anything about the failure, just that it
happened. Which at least will let us communicate that to customers.
This currently has no tests and will need some before landing.
* Address review comments
* Use use statements for config and events
* Add partial test
* Add comment about when save happens
Refactored our PatchInstallEvent to be just PatchEvent
and allow us to have more than one event type.
I moved it into its own events.rs file and added privacy
warnings to both this and the network code (eventually
we may move all this into a separate privacy.rs file).
I also fixed our build.rs file to not panic when our build
is otherwise broken. For whatever reason that seems to
cause the rust-analyzer to stop and not show any future
warnings (thus it's hard to fix things).
I moved away from having a "new" method for PatchEvent
with a series of Strings (which could be confused in order)
and instead am now using just the normal default struct
construction which effectively has named args.
Since EventType is now an enum, it's easy to use the
right enum not have to call PatchInstallEvent::new to
get the right magic string for "identifier".
Also added a bit more documentation to c_api.rs
* fix: use non-blocking http client when reporting launch success
* Make patch install report request on bg thread
* Pass client_id instead of state
* Convert client_id from &str to String
* feat: add client_id to UpdaterState
* feat: add support for reporting patch install events
* Ensure we save UpdaterState after it's created
* Save state if we assign it a client id on load
* Don't error in report_launch_success if no patch exists
* coverage
* Rename
* Minor refactor
* coverage
* coverage
* Update library/src/updater.rs
Co-authored-by: Felix Angelov <felix@shorebird.dev>
* restore debug logs
* make test serial
---------
Co-authored-by: Felix Angelov <felix@shorebird.dev>
* feat: add support for parsing auto_update from shorebird.yaml
The actual support will be in the C++ engine, but this keeps
all yaml parsing in the Rust code for simplicity.
---------
Co-authored-by: Felix Angelov <felix@shorebird.dev>
This is all for shorebirdtech/shorebird#695
I ended up fixing a lot of things in our Rust code while I was in there, including:
* Using PathBuf instead of Sting wherever we are holding onto Path objects (this removed a bunch of code which was converting in and out of these).
* Made a variety of functions private (the default) that were previously mistakenly pub.
* Moved the android hacks around libapp_paths closer to the C++ code. Previously we were storing all of the libapp_paths on ResolvedConfig and handling the android hacks during patch install. Now we're doing the android path hacks on init, eventually we'll remove them entirely by making the C++ code pass us in the android app_dir or even the resolved .apk we need instead of the libapp_paths.
* Fixed several tests to use /dir/lib/arch/libapp.so paths instead of 'libapp.so' now that the init code applies the android hacks an expects the deeper paths. Again, this will go away when we move the android hacks into c++.
* Added a test which confirms that if we init twice we log instead of trying to init again (this was one behavior which FCM was triggering as part of fix: ANR when using Firebase Cloud Messaging with Shorebird shorebird#695
* Add a test which confirms that further calls to update while an update is ongoing just fail out quickly instead of hanging.
* Moved to serial_test instead of a separate per-thread config system for testing. This makes our tests operate more like the code does in the wild, at the cost of needing to annotate a test as #[serial] any time it needs to use shorebird_init.
* Removed ResolvedConfig and now call it UpdateConfig. ResolvedConfig previously had a bool on it to tell if it was initialized, that's now represented as Option instead which is more rusty.
* Changed how we handle NetworkHooks from being compile-time test switched to using function pointers held off of UpdateConfig.network_hooks. I think this makes more sense? I did this to remove the special ThreadConfig object which was used during unit tests, but didn't exist in production. I think the way we mock networking could still be improved.
Each unwrap() is a potential crash. Shorebird's updater code
should never crash.
There still are a couple, but I think we should set up coverage
first so we can track that we're testing all these changes.
Adds support for iOS to the updater library.
Refactored the android-specific code into an android module.
The tests still mostly use the android code, rather than testing iOS paths too, but that can be fixed in a follow-up.
I had to change how "latest patch number" works to understand when patch files disappear from disk (which I thought was happening on iOS initially).
I also had to make status.json not store absolute paths to patch files (since the absolute path changes per-xcode run on iOS).
* Make our rust tests use per-thread config rather than global static
This lets our unit tests run in parallel. I also moved our "integration"
tests back to be unit tests for now.
This also exposes a network mocking abstraction.
I've added an incomplete test of applying a full patch. Still
needs some work to complete.
* Finish making the patch success test work
* Changed our test config to use println instead of info/error, etc. so that tests show output on failure (there might be a better way?)
Unfortunately macro_use (which is the way we were causing error!, info! etc to appear everywhere with only one global import before, only works on crates not on std, so I had to be explicit with my imports per-file.
* Add a function to build a fake zip file, because that's what the updater currently expects. Better would be for us to move to a AssetManager system I suspect, then the updater would ask the asset manager for the libapp.so and we'd return it instead of having to go through writing out a zip file.
* Added a string_patch.rs tool and shared code between that and the patch tool. This made it possible/easy for me to generate the necessary binary patches as well as needed hashes to pretend to be the patch server.
* Added one simple test of the patch tool core logic.
In total we're now above 80% coverage of our rust code after this.
* remove stray comment
This removes another source of possible crashes from the rust code.
I also took this opportunity to try and test the C-api. I also
discovered rust "integration tests" as part of this and chose
to move some of the (new) c_api tests to an integration test
as well as the existing rust api (updater.rs) tests.
* feat: Add start_updater_thread to update off the main thread
This makes it so that clients can easily not block when wanting to
queue an update.
I have a separate patch which updates the Engine to use this new
API.
I also needed to split the concept of the "next_boot" patch
from the "current_boot" patch, previously refered to as
"current" or "active" patch. This required adding a
report_launch_start api to let the updater library know
when to set current_boot patch from next_boot.
I also removed the rust updater/cli in this as well as the
vmpath argument to init.
I also exposed the report_launch_success api, but its not yet
used by the Engine.
I renamed report_failed_launch to report_launch_failure to match
report_launch_start which I introduced.
* Update naming per comments from Felix.
Also added a helper for char* allocation (not sure if it's better).
* Update library/src/updater.rs
---------
Co-authored-by: Felix Angelov <felix@shorebird.dev>
Bryan Oltman