Added flags to:
- Request the session scope.
- Control how log messages get printed to the console.
Updated the code to re-authenticated using the existing data rather than
throwing it away and starting from scratch.
These changes make it possible to repro
https://bugzilla.mozilla.org/show_bug.cgi?id=1887071
- run `cargo run -- --log -d devices` with fresh credentials.
- Any command should do, but I used `devices`
- The client should ask you to login and paste your credentials
- You should see the device list printed out
- In a browser session, change your FxA password
- run `cargo run -- --log -d devices` again
- The client should tell you there was an auth-problem and ask you to
reauthenticate.
- After you paste the reauthentication URL you should see an error
printed out
Changed the ingestion code to prepare statements outside of any loops
rather than creating them on each iteration. Also, use tuples rather
than named arguments. This cuts ingestion time in half for the 2 record
types that dominate the total time:
```
ingest/ingest-amp-wikipedia
time: [446.26 ms 446.85 ms 447.53 ms]
change: [-51.727% -51.566% -51.408%] (p = 0.00 < 0.05)
Performance has improved.
ingest/ingest-amp-mobile
time: [240.08 ms 240.25 ms 240.48 ms]
change: [-49.921% -49.801% -49.672%] (p = 0.00 < 0.05)
Performance has improved.
```
Refactored the prepare and execute calls into their own struct. This
way it's easy to make sure that the arguments line up correctly with the
statement placeholders. I also think it simplifies things to remove the
specifics of each SQL statement from the general ingestion logic.
A side issue here is that there are inherint methods with the same
method names as these traits. This is normally not a big deal because
inherent methods have a higher precedence than trait methods. However,
the methods also take `&mut self` and which has a lower precedent than
`&self` and this rule as a higher precedence (meta-precedence?) than the
other rule.
I prefixed the inherint method names with `filter_` and everything seems
to work okay.
Dismissed suggestion Url hashes are stored in the database and the
suggestions are not returned again in subsequent queries.
This currently works with most providers, but not Yelp or Weather.
I was getting this message when running
`tools/regenerate_dependency_summaries.sh`
```
warning: `/home/ben/application-services/main/.cargo/config` is deprecated in favor of `config.toml`
note: if you need to support cargo 1.38 or earlier, you can symlink `config` to `config.toml`
Updating git repository `https://github.com/martinthomson/ohttp.git`
```
- Use the `data_path` rather than `cache_path` for the suggest DB. This
is prep for for storing the suggestion dismissal data in the DB, which
should not be reset on schema upgrades.
- Don't always drop and recreate the database when the schema upgrades.
Instead, I'm hoping we can use the code from `SuggestDao.clear` to
delete the suggestion data so that we re-ingest it.
- Other than adding the `dismissed_suggestions` table, this doesn't
implement any of the suggestion dismissal functionality.
Added boilerplate for UniFFI, error handling, databases, etc. I tried
to follow the best practices from other application-services components.
Created the initial types and methods for the API. I think all of these
should be considered works-in-progress. It seems likely that some or
all of them will change as we implement the functionality.
Added some code to read / write URL interest data from a test binary
file currently stored in the repo. This is also a WIP, at the very
least it needs to change to download the data from remote settings.
Parse the `full_keyword` field for downloaded AMP / wikipedia
suggestions and store it in the DB.
Use the field for AMP suggestions rather than the current
hueristic-based code.
Don't use this field for Wikimedia suggestions. This is because the
full keyword field is just the full article title, which is already
included in the suggestion.
This helps with keeping track of the last ingested item for each
of the record types.
Update components/suggest/src/store.rs
Co-authored-by: Nan Jiang <njiang028@gmail.com>
Update components/suggest/src/store.rs
Co-authored-by: Nan Jiang <njiang028@gmail.com>
Update components/suggest/src/store.rs
Co-authored-by: Nan Jiang <njiang028@gmail.com>
Handle the case where a public event results in an immediate public
state transition (i.e. the initial state of the internal state machine
is `Complete(new_state)`). Copied the code that does this from
`handle_internal_event` to `handle_public_event`.
Also reworked a couple of the breadcrumb messages. In particular, I got
confused because was both the public and internal event handlers sent
out breadcrumbs that look the same.