Integrate Sentry and implement a feature flagged feature (disabled by default)
to force crash the app using the function mobile/status.go#IntendedPanic()
provided by status-go. Because the feature is feature flagged and disabled, it
is not available in release builds.
Fixes: https://github.com/status-im/status-mobile/issues/21656
Documentation about Sentry in status-go:
https://github.com/status-im/status-go/blob/3466ac2661bb19cd0eaa27761551de3b4d31b393/internal/sentry/README.md#L60
Areas that may be impacted: Whenever a panic happens in status-go and usage data
collection is enabled we will send error data to Sentry. In theory, nothing
should change for the user, therefore nothing should be visibly different in the
app's behavior.
Steps to test:
Before following the steps below, the CI must be configured with the appropriate
SENTRY_DSN_STATUS_GO value. You can also use a free tier cloud instance to do
your own testing in case you want to play around with Sentry.
1. Login with any profile.
2. Enable usage data collection (for now, Sentry and analytics are tied to the
same setting in status-go).
3. Go to Settings > Feature flags and enable app-monitoring > intentional-crash
4. Go to Settings > Advanced > and press on Force crash immediately
Usually you should see the error in the Sentry dashboard in a matter of seconds.
https://github.com/status-im/status-go/compare/032eb5b6...c014fbfc
- Rename LOG_REQUEST_GO env variable to API_LOGGING_ENABLED across all env files
- Rename requests.log to api.log for consistency
- Remove standalone initLogging functionality from native modules as it's now
handled within InitializeApplication
- Add logging configuration (logEnabled, logLevel, apiLoggingEnabled) to
InitializeApplication params
- Add logDir parameter for Android to ensure proper log file location
This change consolidates logging initialization into the InitializeApplication
flow and makes the naming more consistent with its actual functionality.
this commit implemented logging request/response between status-mobile and status-go.
to access `requests.log`, shake your phone and share the logs.
TBD:
- adding `device id` into request to proxy server, we can implement it in a separate PR if needed.
- not sure if we need logging the request made in the backend that not asked by frontend directly
* fix(wallet): fix bridge transactions
Signed-off-by: Brian Sztamfater <brian@status.im>
* add support for approve transactions
Signed-off-by: Brian Sztamfater <brian@status.im>
---------
Signed-off-by: Brian Sztamfater <brian@status.im>
We do a few things to reduce the initial load and make the app more responsive
after login. The scenario we are covering is a user who joined communities with
a large number of members and/or which contain token-gated channels with many
members.
- Related to https://github.com/status-im/status-mobile/issues/20283
- Related to https://github.com/status-im/status-mobile/issues/20285
- Optimize how we convert a community from JS to CLJS. Community members and
chat members are no longer transformed to CLJS, they are kept as JS. Read more
details below.
- Delay processing lower-priority events by creating a third login phase. The
goal is to not put on the same queue we process communities less important
events, like fetching the count of unread notifications. Around 15 events
could be delayed without causing trouble (and this further prevent a big chain
of more events to be dispatched right after login).
- Tried to use re-frame's flush-dom metadata, but removed due to uncertainty,
check out the discussion:
https://github.com/status-im/status-mobile/pull/20729#discussion_r1683047969
Use re-frame’s support for the flush-dom metadata whenever a signal arrives.
According to the official documentation, this should tell re-frame to only
process the event after the UI has been updated. It’s hard to say if this
makes any difference, but the theory is sound.
- Reduce the amount of data returned to the subscription that renders a list of
communities. We were returning too much, like all members, chats, token
permissions, etc.
Other things I fixed or improved along the way:
- Because members are now stored as JS, I took the opportunity to fix how
members are sorted when they are listed.
- Removed a few unused subs.
- Configured oops to not throw during development (in production the behavior is
to never throw). This means oops is now safe to be used instead of interop
that can mysteriously fail in advanced compilation.
- Show compressed key instead of public key in member list for the account
currently logged in.
Technical details
The number one reason affecting the freeze after login was coming from
converting thousands of members inside communities and also because we were
doing it in an inefficient way using clojure.walk/stringify-keys. We shouldn't
also transform that much data on the client as the parent issue created by
flexsurfer correctly recommends. Ever since PR
https://github.com/status-im/status-mobile/pull/20414 was merged, status-go
doesn't return members in open channels, which greatly helps, for example, to
load the Status community. The problem still exists for communities with
token-gated channels with many members.
The current code in develop does something quite inefficient: it fetches the
communities, then transforms them recursively with js->clj and keywordizes keys,
then transforms again all the potentially thousands of member IDs back to
strings. This PR changes this. We now shallowly convert a community and ignore
members because they can grow too fast. From artificial benchmarks simulating
many members in token-gated channels, or communities with thousands of members,
the improvement is noticeable.
You will only really notice improvements if you have spectated or joined a
community with 1000+ members and/or a community with many token-gated channels,
each containing perhaps hundreds of members.
What's the ideal solution?
We should consider removing community members and channel members from the
community entity returned by status-go entirely. The members should be a
separate resource and paginated so that the client doesn't need to worry
about the number of members, for the most part.
This commit:
- update the connection string validation method to use the method from status-go
- updates the error message if the user tries to scan a different key pair QR for importing a missing key pair
- updates the text for exporting an individual key pair
Signed-off-by: Mohamed Javid <19339952+smohamedjavid@users.noreply.github.com>
https://github.com/status-im/status-go/compare/6e056348...1ef2434b
This commit adds support for pushing centralized metrics to mixpanel.
It uses an interceptor and only picks a few selected events to push
through.
In order to test:
1) Create an account in the app
2) Go to Settings->Privacy
3) Enable metrics
You should now see the events on the mixpanel dashboard (login with your
status-im account for access).
Only some example events are tracked, they are just for testing
* fix: ensure missing key pairs scroll with list
* chore: add translations for labels
* chore: promisify validate-mnemonic native module function
* chore: add events for validating seed-phrases and making key-pairs fully operable with seed-phrase
* chore: define re-usable effects for validate-mnemonic and make-seed-phrase-keypair-fully-operable and import-keypair-by-seedphrase
* tweak: refactor error handling logic when importing key-pair by seed-phrase
* tweak: handle vectors and functions between events and effects
* tweak: refactor recover-phrase form to support custom title, children, and navigation icon
* tweak: add support for accessing input-ref in recovery-phrase form
* tweak: always mask seed-phrase when passing to render-controls
* feature: add initial screen for importing key-pair with seed phrase
* tweak: conditionally render keypair context tag inside recovery-phrase form
* tidy: rename on-input-ref to ref
* tidy: remove unused property
* tidy: refactor to use case expression
* tidy: format
In this commit we nuke the unmaintained library `react-native-mail` and move over the logic to our native modules.
This also helps to fix `make nix-update-gradle` which would fail because of that library.
- Android
- iOS
status: ready
The native module : `react-native-status` has always been 1 big fat file per platform which contained all of the native modules.
In case of Android it was `StatusModule.java`
This commit modularises it & attempts to thin out this 1 big file into these categories:
- `AccountManager.java`
- `EncryptionUtils.java`
- `DatabaseManager.java`
- `UIHelper.java`
- `LogManager.java`
- `NetworkManager.java`
- `Utils.java`
In case of iOS it was `RCTStatus.m`
This commit modularises it & attempts to thin out this 1 big file into these categories:
- `AccountManager.m`
- `EncryptionUtils.m`
- `DatabaseManager.m`
- `UIHelper.m`
- `LogManager.m`
- `NetworkManager.m`
- `Utils.m`
In this commit we also remove a lot of unused native code which has no reference on cljs side.
This PR does a few things:
1) Add fetch messages implementation on any kind of chat. It's behind a
toggle (on by default) as design is still unsure whether we want it,
but it's very useful for debugging.
2) Allow setting light client from mobile
It also partially remove node config management from the clojure part,
as it's better if that's not explicitly managed by clients.
Some parts are still relying on it but they are not functional
(keycard), while others are still using it and will need to be updated
eventually (syncing), in order to get rid completely of node config.
Sets fleet to shards.test
https://github.com/status-im/status-go/compare/90c31afe...1adcf02f
Unshadows all remaining vars in status-mobile, including non
cljs.core/clojure.core ones. The only exceptions are cljs.core/type and
cljs.core/name (which happen quite often, so I'm not sure if it's worth
unshadowing them).
This commit initialises the status-go method `startSearchForLocalPairingPeers` which in turn will produce logs that are important for peer discovery while local pairing and will produce logs important to detect local pairing crashes.
This is a continuation of https://github.com/status-im/status-mobile/pull/16500 (Lint
& fix some shadowed core Clojure(Script) vars).
Notes: As a reminder, the goal is to eventually disallow shadowing core Clojure
vars entirely, but to get there and avoid rebase hell and regressions, we need
to do in smaller steps, especially because we can't safely automate the process
of unshadowing vars.
We are already down from ~500 shadowed core vars to 350 in total.
Why is this PR is using names such as "s", "v" or "sym"? Names such as s or v
are the so called idiomatic names, and are listed in the Clojure Style Guide
https://guide.clojure.style/#idiomatic-names. I used them whenever I felt
appropriate. For the var cljs.core/symbol I opted to use sym, even though the
symbol in question is not necessarily a Clojure symbol, I think the alias
conveys the meaning well enough
(https://www.clojure.org/guides/learn/syntax#_symbols_and_idents).
New vars linted:
- comparator
- identity
- str
- symbol
- val
Outstanding shadowed vars include type, name, hash, comp.
It's well known that shadowing core Clojure vars can lead to unexpected bugs. In
fact, it's a common source of bugs in other languages too. In the status-mobile
repository there are, in total, 562 shadowed vars, ~500 are core vars. Excluding
the "old code" we still have 285 offenders.
In status-mobile I've already seen two bugs caused by shadowed vars, both with
the shadowed var "name". But probably other problems happened in the past, and
others will happen in the future if we don't do something about this. This PR is
also my response to my frustration trying to review PRs and checking for
shadowed vars, humans were not meant for that!
In this commit we are enabling ":shadowed-var" to lint certain (not all) core
vars as errors (not warnings). In future PRs we can gradually unshadow more
vars. For the record, name is shadowed 40 times in the new code and 130 in
total, and type is shadowed 93 times in the new code and 124 in total!
What about non-core vars, should we allow shadowing? There are ~70 non-core
shadowed vars. In my opinion, we should also lint and disallow shadowing
non-core vars, since it may cause the same kind of bugs of shadowing core vars.
But this decision can be left for another moment/issue, after we have fixed the
most prominent problem of shadowing core vars.
Which vars are unshadowed in this PR? I fixed 62 errors and unshadowed
cljs.core/iter, cljs.core/time, cljs.core/count, cljs.core/key,
clojure.core/key.
Resources:
- [clj-kondo linter: shadowed-var](https://github.com/clj-kondo/clj-kondo/blob/master/doc/linters.md#shadowed-var)
https://github.com/status-im/status-go/compare/47711c4f...47711c4f
This commit changes the login endpoint so that it uses LoginAccount.
The main difference is that is consistent with the two others we use for
creation/importing, and this will override the networks and use the
secrets provided.
Icaro Motta