[MelvinBot]

Explanation of Change

On native, split navigators freeze every covered screen by default, including the sidebar. The Account screen (SCREENS.SETTINGS.ROOT) shows the user's status in the top bar avatar, but the status is edited from Profile > Status, which are stacked on top of it. So the status change always reaches the Account screen while it is frozen, and on Android the avatar keeps showing the old emoji after you clear the status.

This PR sets nonTopScreenBehavior: 'none' on the SETTINGS.ROOT screen only, so it stays unfrozen while covered and the avatar updates.

• The Inbox, Workspace and Domain sidebars and all central screens keep freezing on native.
• Web is unchanged, because persistentScreens already keeps this screen unfrozen there.
• No unit test was added, as requested in the issue, since this is a one-line config change.

AI Tests (run by MelvinBot)

• npm run lint-changed: passed
• npm run typecheck: passed
• npm run spell-changed: passed
• npm test -- tests/unit/Navigation: 46 suites, 738 tests passed
• npm run react-compiler-compliance-check check-changed: could not run in the CI sandbox (it couldn't resolve the base branch ref). The change only spreads an options object, so compiler compliance is not expected to change.

Fixed Issues

$ #105198
PROPOSAL: #105198 (comment)

Tests

1. Account > Profile > Status: save a status; verify it appears in Profile and on Account's avatar.
2. Clear status; verify Profile is empty and Account's badge disappears immediately.
3. Cancel an unsaved edit; verify the saved status is unchanged.
4. Reload/relaunch and visit Inbox, Workspaces and Domains (if available). Return to Account; verify the cleared status persists.
5. Web: open /settings and /settings/profile/status signed in and out; verify the page or sign-in opens.

• Verify that no errors appear in the JS console

Offline tests

1. Go offline. Save and clear a status; verify Account's badge updates.
2. Reconnect and reload/relaunch; verify Status stays empty. Restore test settings.

QA Steps

Same as Tests and Offline tests.

• Verify that no errors appear in the JS console

PR Author Checklist

• I linked the correct issue in the ### Fixed Issues section above
• I wrote clear testing steps that cover the changes made in this PR
  • I added steps for local testing in the Tests section
  • I added steps for the expected offline behavior in the Offline steps section
  • I added steps for Staging and/or Production testing in the QA steps section
  • I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
  • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
  • I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).
• I included screenshots or videos for tests on all platforms
• I ran the tests on all platforms & verified they passed on:
  • Android: Native
  • Android: mWeb Chrome
  • iOS: Native
  • iOS: mWeb Safari
  • MacOS: Chrome / Safari
• I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
• I verified any copy / text that was added to the app is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
• If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
• I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
• If new assets were added or existing ones were modified, I verified that:
  • The assets are optimized and compressed (for SVG files, run npm run compress-svg)
  • The assets load correctly across all supported platforms.
• If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
• If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
• If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
• If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
• If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:
  • I verified that all the inputs inside a form are aligned with each other.
  • I added Design label and/or tagged @Expensify/design so the design team can review the changes.
• If the PR adds or modifies the UI:
  • I asked an AI agent to review the changes for accessibility issues and addressed its findings.
  • I tested with a screen reader (VoiceOver on macOS) and verified all new/changed elements are reachable with a logical focus order.
  • I verified all new/changed elements have meaningful accessible names and roles.
  • I verified state changes are announced (e.g. checked/unchecked, expanded/collapsed, selected).
• I added unit tests for any new feature or bug fix in this PR to help automatically prevent regressions in this user flow.
• If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native

Android-pr105306-after-live.mp4

Android: mWeb Chrome

Android-Chrome-pr105306-after-clear-live.mp4

iOS: Native

iOS-pr105306-after-clear-verified.mp4

iOS: mWeb Safari

iOS-Safari-pr105306-after-clear-live.mp4

MacOS: Chrome / Safari

Chrome-pr105306-after-clear-verified.mp4

Safari-pr105306-after-clear-verified.mp4

[MelvinBot]

🤖 Android test steps verification results: ✅ pass

The PR's Tests section is still empty, so I ran the repro steps from the linked issue. On standalone Android, the Account avatar showed the status emoji after saving a status and went back to the plain avatar right after clearing it, with no app reload.

Step	Status
1. Account > Profile > Status opens the Status page The Status page opened with the emoji picker, message field, "Clear after" option, and Save button.	✅
2. Add a status, save it, and go back to Account. The avatar shows the status emoji Set status to 🤩 "Testing PR 105306" and saved. Back on the Account screen, the header avatar showed the 🤩 badge.	✅
3. Go to Account > Profile > Status again and tap "Clear status" The app returned to Profile. The Status row no longer showed the emoji or text.	✅
4. Go back to Account. The avatar no longer shows the status emoji (the fix) The Account screen showed only the plain "M" avatar with no emoji.	✅

---

view run · view recording

[MelvinBot]

The failing check is unrelated to this PR, so I didn't push a code change.

Analysis: validate-perf-tests failed on the Reassure measurement [ReportActionsList] should re-render when the report name changes. The render count was off by about 1.1, and the allowed deviation is 0. This PR only changes the Settings root screen options in SettingsSplitNavigator.tsx. That navigator isn't rendered by the ReportActionsList perf test.

Evidence:

• Changed file: src/libs/Navigation/AppNavigator/Navigators/SettingsSplitNavigator.tsx
• Failure location: the ReportActionsList perf test (failed job)
• The same Reassure workflow also fails and then passes on unrelated branches today, which points to a flaky measurement.

Next step: rerun the failed validate-perf-tests job. It should pass without code changes.

Check independent approval is also failing, but it only clears once a reviewer approves.

---

view run

[MelvinBot]

🤖 Web test steps verification results: ⚠️ partial

The PR's Tests section is still empty, so I ran the repro steps from the linked issue on a narrow web viewport. The Account avatar showed the status emoji after saving a status and went back to the plain avatar after clearing it. I couldn't read the browser console, so the "no JS console errors" step is not fully verified.

Step	Status
1. Account > Profile > Status opens the Status page The Status page opened with the emoji button, message field, and Save button.	✅
2. Add a status, save it, and go back to Account. The avatar shows the status emoji Set status to 😀 "Testing PR 105306" and saved. Back on the Account screen, the header avatar showed the 😀 badge.	✅
3. Go to Account > Profile > Status again and tap "Clear status" The app returned to Profile. The Status row no longer showed the emoji or text.	✅
4. Go back to Account. The avatar no longer shows the status emoji The header avatar showed the plain "MT" initials with no emoji.	✅
5. No errors appear in the JS console The web test tool can't capture console logs. No error banners or broken UI appeared during the flow, but the console itself was not checked.	⚠️

---

view run · no recording available

[nyomanjyotisa]

@MelvinBot please replace ### Tests through ### Screenshots/Videos with the following. Keep this PR in draft.

Updated PR description

Tests

1. Account > Profile > Status: save a status; verify it appears in Profile and on Account's avatar.
2. Clear status; verify Profile is empty and Account's badge disappears immediately.
3. Cancel an unsaved edit; verify the saved status is unchanged.
4. Reload/relaunch and visit Inbox, Workspaces and Domains (if available). Return to Account; verify the cleared status persists.
5. Web: open /settings and /settings/profile/status signed in and out; verify the page or sign-in opens.

• Verify that no errors appear in the JS console

Offline tests

1. Go offline. Save and clear a status; verify Account's badge updates.
2. Reconnect and reload/relaunch; verify Status stays empty. Restore test settings.

QA Steps

Same as Tests and Offline tests.

• Verify that no errors appear in the JS console

PR Author Checklist

• I linked the correct issue in the ### Fixed Issues section above
• I wrote clear testing steps that cover the changes made in this PR
  • I added steps for local testing in the Tests section
  • I added steps for the expected offline behavior in the Offline steps section
  • I added steps for Staging and/or Production testing in the QA steps section
  • I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
  • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
  • I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).
• I included screenshots or videos for tests on all platforms
• I ran the tests on all platforms & verified they passed on:
  • Android: Native
  • Android: mWeb Chrome
  • iOS: Native
  • iOS: mWeb Safari
  • MacOS: Chrome / Safari
• I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
• I verified any copy / text that was added to the app is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
• If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
• I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
• If new assets were added or existing ones were modified, I verified that:
  • The assets are optimized and compressed (for SVG files, run npm run compress-svg)
  • The assets load correctly across all supported platforms.
• If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
• If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
• If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
• If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
• If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:
  • I verified that all the inputs inside a form are aligned with each other.
  • I added Design label and/or tagged @Expensify/design so the design team can review the changes.
• If the PR adds or modifies the UI:
  • I asked an AI agent to review the changes for accessibility issues and addressed its findings.
  • I tested with a screen reader (VoiceOver on macOS) and verified all new/changed elements are reachable with a logical focus order.
  • I verified all new/changed elements have meaningful accessible names and roles.
  • I verified state changes are announced (e.g. checked/unchecked, expanded/collapsed, selected).
• I added unit tests for any new feature or bug fix in this PR to help automatically prevent regressions in this user flow.
• If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native

Android-pr105306-after-live.mp4

Android: mWeb Chrome

Android-Chrome-pr105306-after-clear-live.mp4

iOS: Native

iOS-pr105306-after-clear-verified.mp4

iOS: mWeb Safari

iOS-Safari-pr105306-after-clear-live.mp4

MacOS: Chrome / Safari

Chrome-pr105306-after-clear-verified.mp4

Safari-pr105306-after-clear-verified.mp4

[MelvinBot]

🤖 I replaced ### Tests through ### Screenshots/Videos in the PR description with your version. The Explanation of Change and Fixed Issues sections are unchanged. The PR is still a draft.

---

view run

[nyomanjyotisa]

@MelvinBot please rerun the Reassure Performance Tests workflow, including fresh measurements. Keep this PR in draft; no code changes.

[MelvinBot]

I couldn't rerun the Reassure Performance Tests workflow. My run environment blocked the rerun command, so no new run started. The PR is still a draft, and I made no code changes.

To get fresh measurements, open the run and choose Re-run all jobs. Don't choose Re-run failed jobs. That option reruns only validate-perf-tests, which compares the old baseline and branch results again.

Why the last run failed

The run tested the current PR head (b0214a0). baseline-perf-tests and branch-perf-tests passed. validate-perf-tests failed with:

Render count difference exceeded the allowed deviation of 0. Current difference: 1.0999999999999979

---

view run

[nyomanjyotisa]

Reviewer Checklist

• I have verified the author checklist is complete (all boxes are checked off).
• I verified the correct issue is linked in the ### Fixed Issues section above
• I verified testing steps are clear and they cover the changes made in this PR
  • I verified the steps for local testing are in the Tests section
  • I verified the steps for Staging and/or Production testing are in the QA steps section
  • I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
  • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
• I checked that screenshots or videos are included for tests on all platforms
• I included screenshots or videos for tests on all platforms
• I verified that the composer does not automatically focus or open the keyboard on mobile unless explicitly intended. This includes checking that returning the app from the background does not unexpectedly open the keyboard.
• I verified tests pass on all platforms & I tested again on:
  • Android: HybridApp
  • Android: mWeb Chrome
  • iOS: HybridApp
  • iOS: mWeb Safari
  • MacOS: Chrome / Safari
• If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
• I verified any copy / text that was added to the app is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
• If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
• I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
• If a new component is created I verified that:
  • A similar component doesn't exist in the codebase
  • All props are defined accurately
  • The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
  • The only data being stored in the state is data necessary for rendering and nothing else
  • The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions
• If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
• If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
• If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
• If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
• If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:
  • I verified that all the inputs inside a form are aligned with each other.
  • I added Design label and/or tagged @Expensify/design so the design team can review the changes.
• If the PR adds or modifies the UI:
  • I asked an AI agent to review the changes for accessibility issues and addressed its findings.
  • I tested with a screen reader (VoiceOver on macOS) and verified all new/changed elements are reachable with a logical focus order.
  • I verified all new/changed elements have meaningful accessible names and roles.
  • I verified state changes are announced (e.g. checked/unchecked, expanded/collapsed, selected).
• For any bug fix or new feature in this PR, I verified that sufficient unit tests are included to prevent regressions in this flow.
• If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
• I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: HybridApp

Android-pr105306-after-live.mp4

Android: mWeb Chrome

Android-Chrome-pr105306-after-clear-live.mp4

iOS: HybridApp

iOS-pr105306-after-clear-verified.mp4

iOS: mWeb Safari

iOS-Safari-pr105306-after-clear-live.mp4

MacOS: Chrome / Safari

Chrome-pr105306-after-clear-verified.mp4

Safari-pr105306-after-clear-verified.mp4

[nyomanjyotisa]

@MelvinBot please mark this PR ready for review. No code or description changes.

[MelvinBot]

🤖 I marked this PR ready for review. I didn't change any code or the description.

---

view run

[melvin-bot]

@nyomanjyotisa Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button]

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-29T10:36:28.844196Z	b0214a0	Draft marked ready

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[nyomanjyotisa]

LGTM!

[MelvinBot]

The validate-perf-tests failure is unrelated to this PR, so I didn't push a code change.

Analysis: The failing measurement is [ReportActionsList] should re-render when the report name changes. Its render count was off by about 1.1, and the allowed deviation is 0. This PR only changes the Settings root screen options in SettingsSplitNavigator.tsx, which the ReportActionsList perf test doesn't render.

Evidence: today, the same measurement fails the same way on unrelated PRs:

• fix/101182: off by 0.7 (run)
• show-auto-export-timing-in-next-step: off by 0.8 (run)
• add-aba-withdrawal-account-setup: off by 0.8 (run)

This test is currently unstable across PRs. It needs a fix on main, not here.

Next step: you can rerun the failed job, but it may fail again until the test is fixed on main. A reviewer can judge it as a known unrelated failure.

Check independent approval clears once a reviewer approves.

---

view run

[nyomanjyotisa]

@arosiclair While working on this PR, I found an existing accessibility bug: the Status Message field uses statusText instead of its translated label for screen readers.

Removing its explicit accessibilityLabel lets TextInput use the translated label. For reference, the First/last name fields already use translated accessible names.

May I handle this in a separate PR under the C+ small-fix process?

[nyomanjyotisa]

@arosiclair Could you rerun the full Reassure workflow? The failure looks unrelated, and Melvin couldn’t rerun it.

[MelvinBot]

validate-perf-tests is still failing for a reason unrelated to this PR, so I didn't push a code change. The fix is to rerun all jobs in the Reassure workflow, not just the failed one.

Why the rerun didn't help: the second attempt reran only validate-perf-tests. That job compares saved results from baseline-perf-tests and branch-perf-tests, and both jobs passed on the first attempt, so neither was rerun. The validation compared the same files again and got the same difference of 1.1. To take new measurements, choose "Re-run all jobs" on the workflow run.

Evidence that it's unrelated

• The failing measurement is [ReportActionsList] should re-render when the report name changes. tests/perf-test/ReportActionsList.perf-test.tsx renders ReportActionsList directly with mocked navigation. It never mounts SettingsSplitNavigator.tsx, which is the only file this PR changes.
• The branch job measures the PR merge ref, so changes on main are already in both measurements.
• Unrelated PRs fail the same test file today:
  • Run 40897110920: should re-render when an unrelated transaction is written, 0.7
  • Run 40896562654: should re-render when an unrelated transaction is written, 0.7
  • Run 40890531591: should re-render when the report name changes, 0.8

Check independent approval will pass once a reviewer approves.

---

view run

[arosiclair]

@arosiclair Could you rerun the full Reassure workflow? The failure looks unrelated, and Melvin couldn’t rerun it.

This is still failing after a retry. Can you reproduce the failure locally?

May I handle this in a separate PR under the C+ small-fix process?

I'm not familiar with the "C+ small-fix process". Is that written down somewhere?

[MelvinBot]

validate-perf-tests is still failing, but this PR doesn't cause it, so I didn't push a code change.

Analysis: The rerun failed on the same Reassure measurement, [ReportActionsList] should re-render when the report name changes. The render count was off by 0.6, and the allowed deviation is 0. This PR only changes the Settings root screen options in SettingsSplitNavigator.tsx, which the ReportActionsList perf test doesn't render.

Evidence: Today, unrelated PRs fail on the same ReportActionsList tests with similar fractional diffs:

• Run 40896562654 (claude-highlightTodayInDatePicker): off by 0.7
• Run 40894537741 (@GCyganek/mweb-landscape-mode/collapsible-report-header): off by 0.6
• Run 40890531591 (ishpaul/675336-duplicate-auth-parts): off by 0.8
• Run 40887454501 (wojtekboman/wise-intake-form-saving): off by 0.6

Next step: The ReportActionsList perf test is flaky across the repo right now. An engineer should either merge without this check or wait for the test to be stabilized.

Check independent approval is also failing, but it only clears once a reviewer approves.

---

view run

[nyomanjyotisa]

@arosiclair I reran the report-name benchmark locally at b0214a0. All 10 measured runs recorded 27 renders, so I couldn’t reproduce CI’s increase from 27.4 to 28.

I also checked the other failures directly:

• #104362: the same report-name test failed by +0.8 renders.
• #105278: the same test failed by +0.6 renders.
• #105171: a related ReportActionsList test failed earlier, then passed on attempt 4 without a head change.

The process I meant is documented in the C+ small-fix guidelines: the C+ asks the assigned internal engineer first; if approved, the engineer creates an issue and the C+ opens a PR with a full diff under 20 lines. My request was for the Status Message field’s accessible name, separately from this CI failure.

[arosiclair]

Thanks for the link. Let's make another issue for that.

@arosiclair While working on this PR, I found an existing accessibility bug: the Status Message field uses statusText instead of its translated label for screen readers.

Removing its explicit accessibilityLabel lets TextInput use the translated label. For reference, the First/last name fields already use translated accessible names.

May I handle this in a separate PR under the C+ small-fix process?

@MelvinBot create a new issue to address this bug. Use the standard issue template and assign me and @nyomanjyotisa

[arosiclair]

Thanks for looking into Reassure Performance Test as well. Looks like it's flakey, so let's ignore that for now.

[MelvinBot]

I created Status page - Message field announces "statusText" instead of its translated label to screen readers from the standard template, and assigned arosiclair and nyomanjyotisa.

It has the template's Bug and Daily labels. It includes the root cause and the suggested fix: remove accessibilityLabel from the Status Message field so TextInput uses the translated label. I found no existing issue for this bug.

The bug was found by reading the code. No one has reproduced it yet, so the staging and platform checkboxes are empty.

---

view run

[github-actions]

🚧 arosiclair has triggered a test Expensify/App build. You can view the workflow run here.

[OSBotify]

✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

[github-actions]

🧪🧪 Use the links below to test this adhoc build on Android, iOS, and Web. Happy testing! 🧪🧪
Built from App PR #105306 with the pinned Mobile-Expensify submodule.

Android 🤖	iOS 🍎
https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-android-Adhoc-e256d0f1-b074b1f-28cd454f22481b22f007b45066ed5e6053b24bd3/index.html	https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-ios-device-AdHoc-e256d0f1-b074b1f-aa64b6920365b78754c0f497628815afbfeb2741/index.html

Web 🕸️
❌ FAILED ❌
The QR code can't be generated, because the Web build failed

---

👀 View the workflow run that generated this build 👀

[OSBotify]

🚀 Deployed to staging by https://github.com/arosiclair in version: 9.5.27-0 🚀

platform	result
🕸 web 🕸	success ✅
🤖 android 🤖	success ✅
🍎 iOS 🍎	success ✅

[MelvinBot]

No help site update needed. This PR fixes a bug where the Account avatar kept showing an old status after you cleared it, so the app now does what users already expect.

---

view run

[OSBotify]

🚀 Deployed to production by https://github.com/blimpich in version: 9.5.27-2 🚀

platform	result
🕸 web 🕸	success ✅
🤖 android 🤖	success ✅
🍎 iOS 🍎	success ✅

Bundle Size Analysis (Sentry):

• Android
• iOS