Refactor: Fullnode facade to Typescript by tuliomir · Pull Request #972 · HathorNetwork/hathor-wallet-lib

tuliomir · 2025-11-24T16:02:12Z

Summary

This PR starts the migration of the Fullnode Facade HathorWallet in src/new/wallet.js from Javascript to Typescript. This file has over 3400 lines and dozens of methods, so the best approach to do this refactor is with steps as small as possible.

The first step is given by this PR:

Rename the file from .js to .ts and fix all references
Type every variable, parameter and output to any ( permission to use any added in a file-wide scale )
Map, coment and register every code issue that arises but do not change any of them

Rationale

Trying to fix any of the issues that arose or start typing would result in a PR difficult to review. This one, even though it changes many lines, is trivial to read as all of them set variables to any.

Fixing any assignments later is trivial because our linter forces us to do so. The work of assigning types to variables can be done with multiple independent easily reviewable PRs in parallel, as long as none of them try to change the same lines

Immediate benefits

As of now, some of the differences between the HathorWallet and HathorWalletServiceWallet are still unmapped. This PR maps them, adds comments for easy reference and provides the starting point to fix them in future PRs

Acceptance Criteria

Migrates the fullnode facade to Typescript
Keeps all of its types as any
Keeps permissive TS rules locally within the scope of the file only

Security Checklist

Make sure you do not include new dependencies in the project unless strictly necessary and do not include dev-dependencies as production ones. More dependencies increase the possibility of one of them being hijacked and affecting us.

codecov · 2025-11-24T16:24:00Z

Codecov Report

❌ Patch coverage is 92.45283% with 20 lines in your changes missing coverage. Please review.
✅ Project coverage is 84.66%. Comparing base (67964f7) to head (eeb9655).
⚠️ Report is 1 commits behind head on master.

Files with missing lines	Patch %	Lines
src/new/wallet.ts	92.57%	18 Missing and 1 partial ⚠️
src/nano_contracts/builder.ts	88.88%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #972      +/-   ##
==========================================
- Coverage   84.75%   84.66%   -0.10%     
==========================================
  Files         112      112              
  Lines        8146     8228      +82     
  Branches     1753     1787      +34     
==========================================
+ Hits         6904     6966      +62     
- Misses       1214     1233      +19     
- Partials       28       29       +1

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

Copilot

Pull request overview

This PR initiates the TypeScript migration of the HathorWallet facade (src/new/wallet.ts) by renaming it from .js to .ts and typing all variables, parameters, and return values as any. The migration includes adding ESLint suppressions and TypeScript's @ts-nocheck directive to allow gradual migration without breaking the build.

Key Changes:

Renamed src/new/wallet.js to src/new/wallet.ts with all types set to any
Added property declarations for storage and logger fields
Updated interface return types to support both wallet facades
Added stub implementations for startReadOnly() and getReadOnlyAuthToken() methods
Enhanced NanoContractTransactionBuilder with null checks via assertWallet() method

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
src/new/wallet.ts	Migrated from JavaScript to TypeScript with `any` types throughout, added property declarations, and stub method implementations
src/new/sendTransaction.ts	Changed wallet property type to `HathorWallet \| null` to accommodate both facades
src/wallet/types.ts	Updated interface return types with union types to accommodate differences between wallet facades
src/wallet/wallet.ts	Added HathorWallet import and unsafe type casts for NanoContractTransactionBuilder compatibility
src/nano_contracts/builder.ts	Added `assertWallet()` guard method to ensure wallet is set before usage
jest-integration.config.js	Updated file path reference from `.js` to `.ts`

Comments suppressed due to low confidence (4)

src/new/wallet.ts:123

The word "proprieties" should be "properties" in this comment.
src/new/wallet.ts:11
The ESLint directive structure is confusing and potentially ineffective. Lines 8-11 disable the ban-ts-comment rule, enable @ts-nocheck, then re-enable the ban-ts-comment rule. However, this is problematic because:

The eslint-enable on line 11 doesn't affect the @ts-nocheck on line 10 (which is a TypeScript directive, not an ESLint rule)
The ban-ts-comment rule is typically used to prevent @ts-ignore and similar directives, but here it's being temporarily disabled just to use @ts-nocheck

Consider simplifying this to just:

/* eslint-disable @typescript-eslint/no-explicit-any */
// @ts-nocheck

Or better yet, as mentioned in another comment, consider removing @ts-nocheck entirely to get actual TypeScript checking benefits.
src/new/wallet.ts:3505

The stub implementations of startReadOnly() and getReadOnlyAuthToken() throw generic Error objects with inconsistent capitalization in the error messages ("Not Implemented" vs "Not implemented."). These should throw a more specific error type like NotImplementedError or at least use consistent error messages. Additionally, consider documenting why these methods are not implemented in this facade.
src/new/wallet.ts:10
The @ts-nocheck directive on line 10 disables all TypeScript checking for this file, which defeats the purpose of migrating to TypeScript. While the PR description mentions this is for gradual migration, having @ts-nocheck means TypeScript provides no benefits at all - not even basic type checking.

Consider using more targeted suppression like @ts-expect-error on specific problematic lines, or removing this directive and fixing the issues incrementally. This would provide immediate value from the TypeScript migration by catching type errors while still allowing the use of any types.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copilot · 2025-11-24T22:09:22Z

src/new/sendTransaction.ts

 * */
 export default class SendTransaction extends EventEmitter {
-  wallet: HathorWallet;
+  wallet: HathorWallet | null;


Changing wallet: HathorWallet to wallet: HathorWallet | null alters the existing API contract. This could introduce potential null reference errors in code that depends on SendTransaction. Since this class is used by both wallet facades, consider whether this change is necessary or if there are other locations in the code that need to be updated to handle the null case safely.

If the wallet can truly be null, ensure all usages of this.wallet in the SendTransaction class properly handle the null case with guards.

This is already ensured, the only change was to make the type declaration comply with the code.

There are code branches that expect this.wallet not to be present.

Copilot · 2025-11-24T22:09:22Z

src/wallet/types.ts

+  getCurrentAddress(options?: { markAsUsed: boolean }): AddressInfoObject | Promise<unknown>; // FIXME: Should have a single return type
+  getNextAddress(): AddressInfoObject | Promise<unknown>; // FIXME: Should have a single return type;


These return type changes with | Promise<unknown> are inconsistent with the actual implementations. The HathorWalletServiceWallet returns Promise<AddressInfoObject> while HathorWallet appears to return AddressInfoObject directly based on the implementation. However, looking at the new wallet.ts file, getCurrentAddress and getNextAddress both return Promise<any>, which means they're actually async and return Promises.

The issue is that the comment says "FIXME: Should have a single return type" but the union type still includes both synchronous and asynchronous return types. If both implementations are actually async (as they appear to be in the migrated code), the return type should just be Promise<AddressInfoObject> without the AddressInfoObject | part.

Suggested change

getCurrentAddress(options?: { markAsUsed: boolean }): AddressInfoObject | Promise<unknown>; // FIXME: Should have a single return type

getNextAddress(): AddressInfoObject | Promise<unknown>; // FIXME: Should have a single return type;

getCurrentAddress(options?: { markAsUsed: boolean }): Promise<AddressInfoObject>;

getNextAddress(): Promise<AddressInfoObject>;

This is one of the mapped issues: the Wallet Service facade returns synchronously and the fullnode facade returns asynchronously.

Fixing it is outside the scope of this PR, we're only mapping and highlighting an existing issue.

Copilot · 2025-11-24T22:09:22Z

src/wallet/types.ts

    options: DestroyAuthorityOptions
  ): Promise<Transaction>;
-  getFullHistory(): TransactionFullObject[];
+  getFullHistory(): TransactionFullObject[] | Promise<unknown>; // FIXME: Should have a single return type;


Similar to getCurrentAddress and getNextAddress, this union type suggests inconsistent implementations. If both facades actually return Promise<unknown>, then the synchronous TransactionFullObject[] part should be removed. The FIXME comment acknowledges this needs fixing, but the actual implementation in the migrated code appears to be async (line 1316 shows async getFullHistory(): Promise<any>), so the return type should just be Promise<TransactionFullObject[]> (or Promise<{[txId: string]: TransactionFullObject}> based on the implementation which returns a keyed object, not an array).

Suggested change

getFullHistory(): TransactionFullObject[] | Promise<unknown>; // FIXME: Should have a single return type;

getFullHistory(): Promise<{[txId: string]: TransactionFullObject}>; // Fixed: Single async return type

Same issue here: the facades have different types of execution. Mapping and highlighting for now.

Copilot · 2025-11-24T22:09:23Z

src/wallet/wallet.ts

  CreateNanoTxData,
 } from '../nano_contracts/types';
 import { WalletServiceStorageProxy } from './walletServiceStorageProxy';
+import { HathorWallet } from '../index';


Importing HathorWallet from the index creates a circular dependency concern. The src/wallet/wallet.ts file imports from src/index which exports from src/lib.ts which in turn imports from both src/wallet/wallet.ts (HathorWalletServiceWallet) and src/new/wallet.ts (HathorWallet).

This import should be changed to import directly from '../new/wallet' to avoid the circular dependency through the index file.

Suggested change

import { HathorWallet } from '../index';

import { HathorWallet } from '../new/wallet';

Good catch. Fixed on eeb9655

Copilot · 2025-11-24T22:09:23Z

src/wallet/wallet.ts

    const builder = new NanoContractTransactionBuilder()
      .setMethod(method)
-      .setWallet(this)
+      .setWallet(this as unknown as HathorWallet) // FIXME: Should accept IHathorWallet instead


This cast through unknown is a code smell indicating a type system issue. The NanoContractTransactionBuilder.setWallet() method expects a HathorWallet instance, but HathorWalletServiceWallet implements IHathorWallet and is not a HathorWallet.

The proper fix would be to make NanoContractTransactionBuilder.setWallet() accept IHathorWallet instead of the concrete HathorWallet class. This would eliminate the need for unsafe type casts and make the builder work with both wallet implementations without forcing a type lie.

Suggested change

.setWallet(this as unknown as HathorWallet) // FIXME: Should accept IHathorWallet instead

.setWallet(this)

That's precisely what the comment is suggesting. The issue is mapped and highlighted.

r4mmer · 2025-11-24T22:40:11Z

src/nano_contracts/builder.ts

+   */
+  private assertWallet(): asserts this is { wallet: HathorWallet } {
+    if (!this.wallet) {
+      throw new TypeError('Wallet is required to build nano contract transactions.');


It was the closest I could get to the type of the error. Since this can be only HathorWallet or null , I decided for a type error.

Do you think a simple Error would be more adequate here?

We could create a custom error or use an existing one.
WalletTypeError or WalletError for instance.

r4mmer · 2025-11-24T22:50:42Z

src/wallet/types.ts

+  getCurrentAddress(options?: { markAsUsed: boolean }): AddressInfoObject | Promise<unknown>; // FIXME: Should have a single return type
+  getNextAddress(): AddressInfoObject | Promise<unknown>; // FIXME: Should have a single return type;


Both of these have the return type Promise<AddressInfoObject>

If you look at the Wallet Service facade, its response is synchronous. I could have added AddressInfoObject | Promise<AddressInfoObject> , but I decided on adhering to the principle of keeping this PR as simple as it could be. I can't use any here, so I used unknown instead.

See the synchronous code below:

hathor-wallet-lib/src/wallet/wallet.ts

Lines 1446 to 1464 in eeb9655

/**

* Get the current address to be used

*

* @memberof HathorWalletServiceWallet

* @inner

*/

getCurrentAddress({ markAsUsed = false } = {}): AddressInfoObject {

const newAddressesLen = this.newAddresses.length;

if (this.indexToUse > newAddressesLen - 1) {

const addressInfo = this.newAddresses[newAddressesLen - 1];

return { ...addressInfo, info: 'GAP_LIMIT_REACHED' };

}

const addressInfo = this.newAddresses[this.indexToUse];

if (markAsUsed) {

this.indexToUse += 1;

}

return addressInfo;

}

It should be async but we can change that later

r4mmer · 2025-11-24T22:51:46Z

src/wallet/types.ts

    options: DestroyAuthorityOptions
  ): Promise<Transaction>;
-  getFullHistory(): TransactionFullObject[];
+  getFullHistory(): TransactionFullObject[] | Promise<unknown>; // FIXME: Should have a single return type;


This should be Promise<TransactionFullObject[]> on both, right?

Yes, it should, but for now it isn't.

See below:

hathor-wallet-lib/src/wallet/wallet.ts

Lines 1625 to 1627 in eeb9655

getFullHistory(): TransactionFullObject[] {

throw new WalletError('Not implemented.');

}

Yeah, this one is not implemented.
We can change the return type without consequences

r4mmer · 2025-11-24T22:55:21Z

src/wallet/wallet.ts

    const builder = new NanoContractTransactionBuilder()
      .setMethod(method)
-      .setWallet(this)
+      .setWallet(this as unknown as HathorWallet) // FIXME: Should accept IHathorWallet instead


was this beaking?

Yes, with the following error:

TS2345: Argument of type this is not assignable to parameter of type HathorWallet Type HathorWalletServiceWallet is missing the following properties from type HathorWallet: logger, setGapLimit, indexLimitLoadMore, indexLimitSetEndIndex , and 38 more.

tuliomir

GitHub is forcing me to add a review so that my responses to comments are placed here.

tuliomir · 2025-11-24T21:45:31Z

src/nano_contracts/builder.ts

  async executeDeposit(
    action: NanoContractAction
  ): Promise<{ inputs: IDataInput[]; outputs: IDataOutput[] }> {
+    this.assertWallet();


Most methods in this file assume this.wallet is present, but never validates it, so it was breaking the build with errors.

The use of this assert method protects and validates the type, however the test adjusments are outside the scope of this PR.

tuliomir · 2025-11-24T22:12:34Z

src/new/sendTransaction.ts

 * */
 export default class SendTransaction extends EventEmitter {
-  wallet: HathorWallet;
+  wallet: HathorWallet | null;


This is already ensured, the only change was to make the type declaration comply with the code.

There are code branches that expect this.wallet not to be present.

tuliomir · 2025-11-24T22:15:09Z

src/wallet/types.ts

+  getCurrentAddress(options?: { markAsUsed: boolean }): AddressInfoObject | Promise<unknown>; // FIXME: Should have a single return type
+  getNextAddress(): AddressInfoObject | Promise<unknown>; // FIXME: Should have a single return type;


This is one of the mapped issues: the Wallet Service facade returns synchronously and the fullnode facade returns asynchronously.

Fixing it is outside the scope of this PR, we're only mapping and highlighting an existing issue.

tuliomir · 2025-11-24T22:16:15Z

src/wallet/types.ts

    options: DestroyAuthorityOptions
  ): Promise<Transaction>;
-  getFullHistory(): TransactionFullObject[];
+  getFullHistory(): TransactionFullObject[] | Promise<unknown>; // FIXME: Should have a single return type;


Same issue here: the facades have different types of execution. Mapping and highlighting for now.

tuliomir · 2025-11-24T22:19:47Z

src/wallet/wallet.ts

  CreateNanoTxData,
 } from '../nano_contracts/types';
 import { WalletServiceStorageProxy } from './walletServiceStorageProxy';
+import { HathorWallet } from '../index';


Good catch. Fixed on eeb9655

tuliomir · 2025-11-24T22:20:27Z

src/wallet/wallet.ts

    const builder = new NanoContractTransactionBuilder()
      .setMethod(method)
-      .setWallet(this)
+      .setWallet(this as unknown as HathorWallet) // FIXME: Should accept IHathorWallet instead


That's precisely what the comment is suggesting. The issue is mapped and highlighted.

tuliomir · 2025-11-24T23:01:34Z

src/wallet/wallet.ts

    const builder = new NanoContractTransactionBuilder()
      .setMethod(method)
-      .setWallet(this)
+      .setWallet(this as unknown as HathorWallet) // FIXME: Should accept IHathorWallet instead


Yes, with the following error:

TS2345: Argument of type this is not assignable to parameter of type HathorWallet Type HathorWalletServiceWallet is missing the following properties from type HathorWallet: logger, setGapLimit, indexLimitLoadMore, indexLimitSetEndIndex , and 38 more.

tuliomir · 2025-11-24T23:03:58Z

src/wallet/types.ts

+  getCurrentAddress(options?: { markAsUsed: boolean }): AddressInfoObject | Promise<unknown>; // FIXME: Should have a single return type
+  getNextAddress(): AddressInfoObject | Promise<unknown>; // FIXME: Should have a single return type;


If you look at the Wallet Service facade, its response is synchronous. I could have added AddressInfoObject | Promise<AddressInfoObject> , but I decided on adhering to the principle of keeping this PR as simple as it could be. I can't use any here, so I used unknown instead.

See the synchronous code below:

hathor-wallet-lib/src/wallet/wallet.ts

Lines 1446 to 1464 in eeb9655

/**

* Get the current address to be used

*

* @memberof HathorWalletServiceWallet

* @inner

*/

getCurrentAddress({ markAsUsed = false } = {}): AddressInfoObject {

const newAddressesLen = this.newAddresses.length;

if (this.indexToUse > newAddressesLen - 1) {

const addressInfo = this.newAddresses[newAddressesLen - 1];

return { ...addressInfo, info: 'GAP_LIMIT_REACHED' };

}

const addressInfo = this.newAddresses[this.indexToUse];

if (markAsUsed) {

this.indexToUse += 1;

}

return addressInfo;

}

tuliomir · 2025-11-24T23:05:23Z

src/wallet/types.ts

    options: DestroyAuthorityOptions
  ): Promise<Transaction>;
-  getFullHistory(): TransactionFullObject[];
+  getFullHistory(): TransactionFullObject[] | Promise<unknown>; // FIXME: Should have a single return type;


Yes, it should, but for now it isn't.

See below:

hathor-wallet-lib/src/wallet/wallet.ts

Lines 1625 to 1627 in eeb9655

getFullHistory(): TransactionFullObject[] {

throw new WalletError('Not implemented.');

}

tuliomir · 2025-11-24T23:06:12Z

src/nano_contracts/builder.ts

+   */
+  private assertWallet(): asserts this is { wallet: HathorWallet } {
+    if (!this.wallet) {
+      throw new TypeError('Wallet is required to build nano contract transactions.');


It was the closest I could get to the type of the error. Since this can be only HathorWallet or null , I decided for a type error.

Do you think a simple Error would be more adequate here?

* Refactor: Fullnode facade to Typescript (#972) * feat: add nano execution logs API (#973) --------- Co-authored-by: Tulio Miranda <tulio.mir@gmail.com>

…-policy * origin/master: (31 commits) feat: fee token creation (#858) fix: checkAddressMine was crashing when called with an empty array (#977) feat: the nano amount field should accept 0 Merge pull request #975 from HathorNetwork/chore/bump-v2.11.0 feat: add nano execution logs API (#973) Refactor: Fullnode facade to Typescript (#972) Merge pull request #970 from HathorNetwork/chore/bump-v2.10.0 fix: added missing tx proposal delete schema (#969) feat: add missing api calls for graphviz and nano (#967) Merge pull request #965 from HathorNetwork/feat/complete-token-info-object chore: bump package to v2.9.1 (#962) feat: catch and store async promise error (#960) chore: bump wallet lib to v2.9.0 (#958) tests: use core v0.67.0 docker image for the integration tests (#956) tests: update integration tests blueprints for the new core sdk (#954) fix: added a minimal accessData so methods that need storage don't crash (#955) feat: fee header (#951) feat: added read-only start (#950) fix: dont add metadata changed for voided txs (#948) test: Wallet Service infrastructure (#909) ...

tuliomir self-assigned this Nov 24, 2025

tuliomir added this to Hathor Network Nov 24, 2025

tuliomir added the refactor label Nov 24, 2025

github-project-automation bot moved this to Todo in Hathor Network Nov 24, 2025

tuliomir added 10 commits November 24, 2025 17:58

refactor: new/wallet.js to typescript

ce08173

refactor: (2) new/wallet.js to typescript

f5e1f28

refactor: (3) new/wallet.js to typescript

74b746e

refactor: (4) new/wallet.js to typescript

7502c46

fix: mandatory properties

45810b8

fix: builder typing

caa69b4

fix: sendTransaction typing

4f1b19f

fix: walletService typing

63f7b9b

fix: inconsistent types between facades

9673109

fix: organize imports

427ef03

tuliomir force-pushed the refactor/fullnode-facade-typescript branch from 7750435 to 427ef03 Compare November 24, 2025 20:58

tuliomir moved this from Todo to In Progress (WIP) in Hathor Network Nov 24, 2025

docs: improve wording

9c5f997

tuliomir changed the title ~~Rrefactor: Fullnode facade to Typescript~~ Refactor: Fullnode facade to Typescript Nov 24, 2025

tuliomir requested a review from r4mmer November 24, 2025 21:39

tuliomir marked this pull request as ready for review November 24, 2025 21:40

tuliomir requested a review from pedroferreira1 as a code owner November 24, 2025 21:40

tuliomir moved this from In Progress (WIP) to In Progress (Done) in Hathor Network Nov 24, 2025

tuliomir requested review from andreabadesso and Copilot and removed request for pedroferreira1 November 24, 2025 22:05

Copilot started reviewing on behalf of tuliomir November 24, 2025 22:05 View session

Copilot finished reviewing on behalf of tuliomir November 24, 2025 22:08

Copilot AI reviewed Nov 24, 2025

View reviewed changes

fix: avoid circular dependency

eeb9655

r4mmer reviewed Nov 24, 2025

View reviewed changes

tuliomir commented Nov 24, 2025

View reviewed changes

tuliomir requested a review from r4mmer November 25, 2025 16:17

r4mmer approved these changes Nov 25, 2025

View reviewed changes

tuliomir moved this from In Progress (Done) to In Review (WIP) in Hathor Network Nov 25, 2025

andreabadesso approved these changes Nov 26, 2025

View reviewed changes

tuliomir merged commit 2db4721 into master Nov 26, 2025
5 checks passed

github-project-automation bot moved this from In Review (WIP) to Waiting to be deployed in Hathor Network Nov 26, 2025

tuliomir deleted the refactor/fullnode-facade-typescript branch November 26, 2025 13:14

pedroferreira1 added a commit that referenced this pull request Nov 26, 2025

Release v2.11.0 (#974)

c8c0409

* Refactor: Fullnode facade to Typescript (#972) * feat: add nano execution logs API (#973) --------- Co-authored-by: Tulio Miranda <tulio.mir@gmail.com>

tuliomir moved this from Waiting to be deployed to Done in Hathor Network Jan 26, 2026

		getCurrentAddress(options?: { markAsUsed: boolean }): AddressInfoObject \| Promise<unknown>; // FIXME: Should have a single return type
		getNextAddress(): AddressInfoObject \| Promise<unknown>; // FIXME: Should have a single return type;

	getFullHistory(): TransactionFullObject[] \| Promise<unknown>; // FIXME: Should have a single return type;
	getFullHistory(): Promise<{[txId: string]: TransactionFullObject}>; // Fixed: Single async return type

	import { HathorWallet } from '../index';
	import { HathorWallet } from '../new/wallet';

	.setWallet(this as unknown as HathorWallet) // FIXME: Should accept IHathorWallet instead
	.setWallet(this)

	/**
	* Get the current address to be used
	*
	* @memberof HathorWalletServiceWallet
	* @inner
	*/
	getCurrentAddress({ markAsUsed = false } = {}): AddressInfoObject {
	const newAddressesLen = this.newAddresses.length;
	if (this.indexToUse > newAddressesLen - 1) {
	const addressInfo = this.newAddresses[newAddressesLen - 1];
	return { ...addressInfo, info: 'GAP_LIMIT_REACHED' };
	}

	const addressInfo = this.newAddresses[this.indexToUse];
	if (markAsUsed) {
	this.indexToUse += 1;
	}
	return addressInfo;
	}

	getFullHistory(): TransactionFullObject[] {
	throw new WalletError('Not implemented.');
	}

Conversation

tuliomir commented Nov 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Rationale

Immediate benefits

Acceptance Criteria

Security Checklist

Uh oh!

codecov bot commented Nov 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Copilot AI Nov 24, 2025

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Copilot AI Nov 24, 2025

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Copilot AI Nov 24, 2025

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Copilot AI Nov 24, 2025

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Copilot AI Nov 24, 2025

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tuliomir left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tuliomir commented Nov 24, 2025 •

edited

Loading

codecov bot commented Nov 24, 2025 •

edited

Loading