fix: infinite reload on txn page

[npv12]

Important

Fixes infinite reload on transaction page and transitions build system from npm to Bun.

• Behavior:
  • Fixes infinite reload on transaction page by adding URL synchronization logic using useRef and useEffect in page.tsx.
  • Introduces hasSyncedFromUrlRef and pendingUrlSyncRef to manage URL sync state.
• Build System:
  • Replaces npm with Bun in frontend-build.yml, frontend-deploy.yml, frontend-lint.yml, and frontend-pr.yml.
  • Updates generate-icons.sh and justfile to use bunx for script execution.
• Documentation:
  • Updates AGENTS.md to reflect Bun usage for development commands.
  • Adds vercel.json to specify Bun version.

^{This description was created by for a448e9b. You can customize this summary. It will automatically update as commits are pushed.}

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed everything up to a448e9b in 2 minutes and 18 seconds. Click for details.

• Reviewed 1539 lines of code in 11 files
• Skipped 1 files when reviewing.
• Skipped posting 9 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. .github/workflows/frontend-build.yml:27

• Draft comment:
  Using the Setup Bun action. Consider pinning the bun version instead of using 'latest' for reproducibility.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 35% vs. threshold = 50% This comment is about a change that was made in the diff (switching to Bun and using 'latest' version). It's a valid best practice suggestion - using 'latest' in CI can lead to non-reproducible builds if Bun releases a breaking change. However, I need to consider the rules: the comment is somewhat advisory/informative rather than pointing out a clear bug. It says "Consider" which makes it a suggestion rather than identifying a definite issue. The rules state "Do NOT comment unless there is clearly a code change required" and "Do NOT make speculative comments." This is more of a best practice suggestion than a required change. The code will work fine with 'latest', it's just not ideal for reproducibility. While this is a valid best practice, the comment uses "Consider" which makes it advisory rather than pointing out a clear defect. The rules emphasize not making comments unless there's clearly a code change required, and this is more of a quality/best practice suggestion rather than a bug or error. However, reproducibility in CI/CD is important enough that this could be considered a clear code quality issue. Using 'latest' can cause builds to break unexpectedly when new versions are released. This is an actionable, specific suggestion that improves the code quality in a meaningful way. This is a borderline case. It's a valid best practice suggestion that's actionable and specific, but it's phrased as advisory ("Consider") rather than identifying a clear defect. Given the emphasis on only keeping comments with strong evidence of being necessary, and that the code works as-is, I'll lean toward removing it.

2. .github/workflows/frontend-deploy.yml:31

• Draft comment:
  Ensure that 'bun install --global vercel@latest' installs Vercel CLI with the expected behavior compared to npm.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 1% This comment is asking the PR author to ensure that a command behaves as expected, which violates the rule against asking the author to ensure behavior is intended or tested. It does not provide a specific suggestion or point out a specific issue.

3. .github/workflows/frontend-lint.yml:39

• Draft comment:
  Using 'bunx prettier --check .' instead of npx. Confirm that 'bunx' provides the same CLI behavior.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% The comment says "Confirm that 'bunx' provides the same CLI behavior." This is explicitly asking the PR author to confirm or verify something, which violates the rule: "Do NOT ask the PR author to confirm their intention, to explain, to double-check things, to ensure the behavior is intended, to make sure their change is tested, or similar." The comment doesn't point out a definite issue - it's speculative and asks for confirmation. bunx is the Bun equivalent of npx and is designed to work the same way. The PR author clearly intended this migration and would have tested it. This is not a useful comment. Perhaps the comment is trying to highlight a potential compatibility issue that the author might not be aware of? Maybe there are known differences between bunx and npx that could cause problems? Even if there were potential compatibility issues, the comment doesn't identify any specific problem - it just asks for confirmation. If there was a known issue with bunx vs npx, the comment should state it directly rather than asking the author to verify. The comment is speculative and asks for confirmation, which violates the rules. This comment should be deleted because it asks the PR author to confirm/verify the behavior rather than pointing out a definite issue. It's a speculative comment that doesn't provide actionable feedback.

4. .github/workflows/frontend-pr.yml:31

• Draft comment:
  Check that installing Vercel CLI via 'bun install --global vercel@latest' maintains the same behavior as the npm equivalent.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 1% This comment is asking the PR author to verify that a change maintains the same behavior as before, which is against the rules. It does not provide a specific suggestion or point out a specific issue with the code.

5. README.md:36

• Draft comment:
  The README now mentions Bun. Make sure instructions for installing and activating Bun (and version management if needed) are clear.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 1% This comment is asking the PR author to ensure that the README is updated with instructions, which is not allowed according to the rules. It is not a specific code suggestion or a request for a test.

6. frontend/app/transaction/page.tsx:210

• Draft comment:
  The updateUrl condition now checks '!hasSyncedFromUrlRef.current'. Verify that this logic prevents infinite reloads without blocking legitimate URL updates.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 1% The comment is asking the PR author to verify the logic, which violates the rule against asking for confirmation or verification. It doesn't provide a specific suggestion or point out a clear issue with the code.

7. frontend/scripts/generate-icons.sh:21

• Draft comment:
  Switched from 'npx' to 'bunx' for executing ts-node and prettier. Confirm that the Bun environment in CI supports 'bunx' as expected.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 1% The comment is asking the author to confirm that the Bun environment in CI supports bunx. This is asking for confirmation of behavior, which violates the rules. The comment does not provide a specific code suggestion or ask for a test to be written.

8. justfile:104

• Draft comment:
  Replaced npm-check-updates with 'bunx npm-check-updates'. Ensure 'bunx' handles the upgrade process equivalently to npx.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 1% The comment is asking the author to ensure that bunx handles the upgrade process equivalently to npx. This falls under the rule of not asking the author to ensure behavior is intended or to double-check things. Therefore, this comment should be removed.

9. .github/workflows/frontend-build.yml:36

• Draft comment:
  There appears to be an extra trailing space at the end of line 36. Consider removing it to keep the file clean.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% The comment is technically correct - there is a trailing space on line 36. However, I need to check if this violates the rules. The rules state "Do NOT make comments that are obvious or unimportant." A trailing space is a very minor formatting issue. The rules also say "Do NOT comment unless there is clearly a code change required" - a trailing space doesn't require a code change for functionality. This is an extremely minor style/formatting issue that most linters would catch automatically. The comment is about something that was changed (the line was modified from npm to bun), but the trailing space itself wasn't introduced by this change - it was already there in the old version. While trailing spaces are generally considered bad practice, this is an extremely minor issue. The comment could be considered useful for code cleanliness, but it might also be considered "obvious or unimportant" per the rules. Additionally, this would likely be caught by automated linters or formatters. The rules explicitly state not to make comments that are "obvious or unimportant," and a single trailing space falls into this category. This is the type of issue that would be automatically caught by linters/formatters in the build process, and the rules say not to comment on things "obviously caught by the build." This comment should be deleted. It's about a trivial whitespace issue that is unimportant and would likely be caught by automated tooling. It doesn't meet the threshold of requiring a clear code change.

Workflow ID: wflow_rSWxGwNpLrhZmaiR

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}