Repository navigation
Conversation
|
@codex review |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f5d36203e2
ℹ️ About Codex in GitHub
Codex has been enabled to automatically 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".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
|
@codex review |
Codecov Report❌ Looks like you've decreased code coverage for some files. Please write tests to increase, or at least maintain, the existing level of code coverage. See our documentation here for how to interpret this table.
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: bbe24fcfa8
ℹ️ About Codex in GitHub
Codex has been enabled to automatically 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".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 00dbfdaae2
ℹ️ About Codex in GitHub
Codex has been enabled to automatically 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".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: e6999a290d
ℹ️ About Codex in GitHub
Codex has been enabled to automatically 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".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
|
@codex review |
|
Codex Review: Didn't find any major issues. Can't wait for the next one! Reviewed commit: ℹ️ About Codex in GitHubCodex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback". |
JakubKorytko
changed the title
|
@ikevin127 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] |
Reviewer Checklist
Screenshots/Videos
|
| function isRecord(value: unknown): value is Record<string, unknown> { | ||
| return !!value && typeof value === 'object' && !Array.isArray(value); | ||
| } |
There was a problem hiding this comment.
🟡 Issue: isRecord duplicates existing utility in ImportOnyxStateUtils.ts
// SearchQueryUtils.ts (line 1936)
function isRecord(value: unknown): value is Record<string, unknown> {
return !!value && typeof value === 'object' && !Array.isArray(value);
}
// ImportOnyxStateUtils.ts (line 13)
function isRecord(value: unknown): value is Record<string, unknown> {
return typeof value === 'object' && !Array.isArray(value) && value !== null;
}Impact: Code duplication. Two identical type guards in the same code base.
Recommendation: Extract isRecord to a shared utility (e.g. @libs/isRecord.ts or @libs/ObjectUtils.ts). The ImportOnyxStateUtils version with explicit value !== null && is slightly more readable.
There was a problem hiding this comment.
moved to @libs/ObjectUtils.ts
| function getNavigateAfterCreateSearchNavigatorState() { | ||
| const rootState = navigationRef.getRootState(); | ||
| const searchNavigatorRoute = rootState?.routes?.findLast((route) => route.name === NAVIGATORS.SEARCH_FULLSCREEN_NAVIGATOR); | ||
| return searchNavigatorRoute?.state; | ||
| } | ||
|
|
There was a problem hiding this comment.
Strength: Extraction of getNavigateAfterCreateSearchNavigatorState into a named function improves readability and testability.
Issue: This new helper does not use the improved getCurrentSearchQueryJSON / getTopmostFullScreenRoute logic. It directly accesses navigationRef.getRootState().
This function skips the new fallback chain entirely. If the SEARCH_FULLSCREEN_NAVIGATOR is inside a TAB_NAVIGATOR but its .state is missing (the scenario this PR fixes), this function returns undefined, and alreadyOnSearchRoot becomes false. This means the telemetry will record NAVIGATE_TO_SEARCH instead of DISMISS_MODAL_ONLY, which may affect performance metrics.
Bug potential: If the SEARCH_FULLSCREEN_NAVIGATOR is not at the root level but nested inside TAB_NAVIGATOR, rootState.routes.findLast(...) will not find it. This is the pre-existing behavior, but the PR doesn't address it. The helper should probably use the same state-finding logic as getCurrentSearchQueryJSON.
| type NavigationRouteLike = { | ||
| key?: unknown; | ||
| name?: unknown; | ||
| params?: unknown; | ||
| state?: unknown; | ||
| }; |
There was a problem hiding this comment.
🟡 Issue: NavigationRouteLike type uses unknown where string would be more precise
Impact: Type safety is weakened. getRouteKey has to do typeof route.key === 'string' because the type allows unknown which defeats the purpose of having a typed structure.
Recommendation:
type NavigationRouteLike = {
key?: string;
name?: string;
params?: Record<string, unknown>;
state?: unknown;
};Then getRouteKey simplifies to:
function getRouteKey(route: NavigationRouteLike | unknown): string | undefined {
return isRecord(route) && typeof route.key === 'string' ? route.key : undefined;
}(Kept the runtime check since route is unknown at call site.)
There was a problem hiding this comment.
I updated the type and since we always pass the route which is NavigationRouteLike | undefined to these accessor functions, there's no point in checking for isRecord and typeof anymore, so I just removed them and inlined the access instead
| function isUnknownArray(value: unknown): value is unknown[] { | ||
| return Array.isArray(value); | ||
| } |
There was a problem hiding this comment.
🟡 Issue: isUnknownArray is just a type-guard wrapper around Array.isArray
This adds function call overhead for minimal value. TypeScript's Array.isArray already narrows to unknown[] when called on unknown. Consider inlining it or keeping it only if strict lint rules require the guard.
There was a problem hiding this comment.
doesn't work, Array.isArray makes the type any[], not unknown[]
| const tabState = { | ||
| stale: false as const, | ||
| type: 'tab', | ||
| key: 'tab-state-key', | ||
| index: 2, | ||
| routeNames: [SCREENS.HOME, NAVIGATORS.REPORTS_SPLIT_NAVIGATOR, NAVIGATORS.SEARCH_FULLSCREEN_NAVIGATOR], | ||
| routes: [ | ||
| {key: 'home-key', name: SCREENS.HOME}, | ||
| {key: 'reports-key', name: NAVIGATORS.REPORTS_SPLIT_NAVIGATOR}, | ||
| {key: 'search-key', name: NAVIGATORS.SEARCH_FULLSCREEN_NAVIGATOR}, | ||
| ], | ||
| }; |
There was a problem hiding this comment.
🟡 Issue: The mock setup mutates a shared tabState object
The index: 2 points to the third route (SEARCH_FULLSCREEN_NAVIGATOR). If a future test changes this index without copying the object, it will break other tests. Consider making tabState a factory function.
ikevin127
left a comment
ikevin127
left a comment
There was a problem hiding this comment.
🟢 LGTM - Tests well, only a few code-related / non-blocking comments.
|
Jakub is OOO, I addressed the review comments |
| type NavigationRouteLike = { | ||
| key?: string; | ||
| name?: string; | ||
| params?: Record<string, unknown>; | ||
| state?: unknown; | ||
| }; |
There was a problem hiding this comment.
Even if these methods are simple, lets create unit tests for them to make sure we gate from some unexpected changes to them
There was a problem hiding this comment.
I added tests for getLastRouteByName, getRoutes, getParamsState and isSearchRootParams. I think the rest should be covered by the getCurrentSearchQueryJSON tests already
|
@mountiny looks like this was merged without a test passing. Please add a note explaining why this was done and remove the |
|
✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release. |
|
🚧 @mountiny has triggered a test Expensify/App build. You can view the workflow run here. |
|
The checklist is filled out, not an emergency |
|
🧪🧪 Use the links below to test this adhoc build on Android, iOS, and Web. Happy testing! 🧪🧪
|
|
🚀 Deployed to staging by https://github.com/mountiny in version: 9.4.16-1 🚀
Bundle Size Analysis (Sentry): |
|
🤖 No help site changes required. I reviewed the changes in this PR against the help site content in
The end-user flow documented on the help site is unchanged: create a scan expense from global create, submit, and return to the Spend page. The only difference is that this flow no longer stalls (the 40–50s If you believe a help article should be updated to describe behavior I may have missed, reply with the specific article and behavior and I'll take another look. @JakubKorytko, please confirm you agree no help site updates are needed. If you spot a doc that should change, let me know and I'll open a draft PR. |
|
🚀 Deployed to production by https://github.com/blimpich in version: 9.4.16-5 🚀
|
Explanation of Change
Fixes a
submit-to-destination-visiblespan failure identified from 3 Sentry traces on iOS HybridApp.Global create scan from Spend misidentifies Search context (traces
d0c23d02,2a89ae3d,9789e05e, iOS HybridApp, 44.5–50.6s): live tab state can be unavailable when mobile navigator state is lazy, sliced, or being restored.getTopmostFullScreenRoute()now falls back from live tab state to preserved tab state soisSearchTopmostFullScreenRoute()can still detectSearchFullscreenNavigatorwhen preserved state is available. It intentionally does not useparams.screenas current focus because that value can be a stale initial deep-link hint.navigateAfterExpenseCreateno longer infers Search root from missing navigator state, and Search query helpers read nested Search params before falling back to the default query.Fixed Issues
$ #93725
PROPOSAL: N/A
Tests
ManualSubmitToDestinationVisiblespan end log thatfast_path_handlerissearch_dismiss, notdefaultOffline tests
N/A
QA Steps
Same as tests.
PR Author Checklist
### Fixed Issuessection aboveTestssectionOffline stepssectionQA stepssectiontoggleReportand notonIconClick)src/languages/*files and using the translation methodSTYLE.md) were followedAvatar, I verified the components usingAvatarare working as expected)StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))npm run compress-svg)Avataris modified, I verified thatAvataris working as expected in all cases)Designlabel and/or tagged@Expensify/designso the design team can review the changes.ScrollViewcomponent to make it scrollable when more elements are added to the page.mainbranch was merged into this PR after a review, I tested again and verified the outcome was still expected according to theTeststeps.Screenshots/Videos
Android: Native
Scan_Android.mov
Android: mWeb Chrome
iOS: Native
Scan_iOS.mov
iOS: mWeb Safari
MacOS: Chrome / Safari