Skip to content

rebase#2727

Merged
leonarduk merged 6 commits into
codex/fix-issue-#2710-on-githubfrom
main
Apr 2, 2026
Merged

rebase#2727
leonarduk merged 6 commits into
codex/fix-issue-#2710-on-githubfrom
main

Conversation

@leonarduk

Copy link
Copy Markdown
Owner

No description provided.

@leonarduk leonarduk self-assigned this Apr 2, 2026
@chatgpt-codex-connector

Copy link
Copy Markdown

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

@leonarduk leonarduk merged commit f7f5d7b into codex/fix-issue-#2710-on-github Apr 2, 2026
7 of 9 checks passed
@github-actions

github-actions Bot commented Apr 2, 2026

Copy link
Copy Markdown

GPT AI Code Review

1. Acceptance criteria

There are no linked issues or acceptance criteria provided, so I will assess the changes based on the diff alone. The changes appear to focus on the ConfigContext component in the frontend, specifically around managing the base currency and ensuring that the configuration does not refetch unnecessarily when the base currency changes. The addition of the BaseCurrencySetter component and the associated test case suggests that the functionality is being enhanced to handle local changes to the base currency without triggering a refetch of the configuration. Overall, the changes seem to be well-scoped and complete.

2. Bugs and logic errors

The logic in the ConfigProvider component appears sound. The use of previousConfig.baseCurrency ensures that the existing base currency is preserved when updating the configuration. The test case for ensuring that the configuration does not refetch when the base currency changes locally is a good addition. However, it would be prudent to consider edge cases, such as what happens if the base currency is set to an invalid value or if the setBaseCurrency function fails for any reason. These scenarios are not explicitly handled in the current implementation.

3. API, data, and workflow safety

The changes do not appear to alter the shape of the data being passed between the backend and frontend, particularly regarding the configuration object. The test case verifies that the getConfig function is called only once, which should help maintain the integrity of the workflow. There are no indications that this PR would break local smoke tests or deployment workflows. The handling of secrets and permissions is not directly addressed in this diff, but since it primarily deals with frontend configuration, it seems safe in that regard.

4. Test coverage

The new test case added in ConfigContext.familyMvp.test.tsx effectively covers the scenario of changing the base currency locally without triggering a refetch of the configuration. This is a positive addition to the test suite. However, as mentioned earlier, it might be beneficial to add tests for edge cases, such as invalid currency values or potential failures in the setBaseCurrency function.

5. Minor issues (optional)

The code style and naming conventions appear consistent with the existing codebase. The use of previousConfig is clear and descriptive. However, consider adding comments to clarify the purpose of the BaseCurrencySetter component and the rationale behind not refetching the configuration when the base currency changes. This would enhance maintainability for future developers.

Summary Verdict: APPROVE


Reviewed by GPT via gpt-pr-review.yml. Advisory only.

@github-actions

github-actions Bot commented Apr 2, 2026

Copy link
Copy Markdown

Claude AI Code Review

Review: rebase PR

1. Acceptance criteria

No linked issue. The PR title "rebase" suggests this is a rebase cleanup rather than a feature — but the diff contains a genuine bug fix and a new test. I'll review on its own merits.


2. Bugs and logic errors

The core fix (lines ~188-207 in ConfigContext.tsx) is correct and addresses a real bug.

The previous code captured config.baseCurrency by closure in refreshConfig:

// Before
baseCurrency: config.baseCurrency,
}, [config.baseCurrency]);

This caused refreshConfig to be recreated every time baseCurrency changed (e.g. user switching currency), which would re-trigger the useEffect(() => { refreshConfig() }, [refreshConfig]) downstream — causing an unintended API refetch loop. The fix uses the functional setState form to read the previous state instead, and removes the stale closure dependency entirely.

One concern: removing config.baseCurrency from the dependency array and replacing with [] is correct only if refreshConfig has no other state/prop dependencies that could go stale. Looking at the function body, it also references setConfig, applyTheme, and the getConfig API call — all of which are either stable refs or module-level imports, so [] is correct here. No issue.

Edge case not handled: If refreshConfig is called manually (e.g. via a refresh button) after baseCurrency has been set to a non-default value, the functional updater previousConfig.baseCurrency correctly preserves the user's selection. ✅


3. API, data, and workflow safety

No backend contract changes. The diff is entirely frontend state management. The getConfig API response shape is unchanged and not touched here.

No CI/deployment risk. No config files, CDK, or environment changes are included.

One subtle workflow concern: The useCallback with [] deps means refreshConfig is now a stable function reference for the component's lifetime. This is the correct behavior — but it's worth noting that if future developers add new external dependencies to refreshConfig, they'll need to remember to add them to the dep array. A code comment explaining why [] is intentional would help prevent future regressions. Minor, but worth flagging.


4. Test coverage

The new test ("does not refetch config when base currency changes locally") directly validates the fix:

  • Mounts ConfigProvider with BaseCurrencySetter which calls setBaseCurrency("USD") on mount
  • Asserts getConfig is called exactly once (not re-called due to currency change)
  • Asserts the rendered currency is "USD"

This is good. A couple of gaps:

Missing test case: What happens when refreshConfig is called after setBaseCurrency("USD")? The test confirms no spurious refetch, but doesn't verify that a deliberate subsequent call to refreshConfig still preserves baseCurrency: "USD" (i.e., the functional updater path). This would complete confidence in the fix.

beforeEach(() => { vi.clearAllMocks() }) — good addition, prevents mock state leaking between tests. The previous lack of this was a latent issue.

BaseCurrencySetter component — the useEffect with [setBaseCurrency] dep is fine since setBaseCurrency is wrapped in useCallback and should be stable.


5. Minor issues

  • The blank line removal at line 135 (-) is noise from the rebase — harmless but confirms this is a messy rebase rather than a clean PR.
  • The PR title "rebase" is not descriptive. This should be titled something like fix: avoid refreshConfig loop when baseCurrency changes. This matters for changelog/blame readability.
  • No inline comment explaining why [] is the correct dep array for refreshConfig's useCallback. Given this was a subtle bug, future maintainers deserve the explanation.

Verdict: COMMENT — the fix is correct and the test validates it, but the missing test for the refreshConfig-after-currency-change path and the absent explanatory comment on the empty dep array are worth addressing before merge.


Reviewed by Claude via claude-pr-review.yml. Advisory only.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant