Improve normalize error by dajimenezriv-internxt · Pull Request #382 · internxt/sdk

dajimenezriv-internxt · 2026-04-09T12:38:34Z

What

I had multiple tickets that ended in the normalizeError and some information is missing, like which url is failing or similar things. I've been touching a bit the sdk so the errors include information that maybe it's useful, but I want to be sure that I don't break anything in any other platform. There are going to be 2 use cases, one in which the response fails and the other in which there is no response (for example because a timeout).

In case of response, the error received will be something like this:

In case of no response the error will have this format:

I've mantained the status code that we had before.

dajimenezriv-internxt · 2026-04-09T12:52:03Z

src/network/upload.ts

  };

-  const finishUploadResponse = await network.finishUpload(bucketId, finishUploadPayload, signal);
+  const finishUploadResponse = await network.finishMultipartUpload(bucketId, finishUploadPayload, signal);


This was a "bug" since multipart was also using finishUpload. They do the same but finishMultipartUpload performs 2 additional checks.

dajimenezriv-internxt · 2026-04-09T12:52:39Z

src/utils.ts

@@ -1,23 +1,3 @@
-import { AxiosError, AxiosResponse } from 'axios';
-
-export function extractAxiosErrorMessage(err: AxiosError): string {


This was no used in any project of Internxt.

dajimenezriv-internxt · 2026-04-09T12:56:13Z

.prettierrc.js

@@ -0,0 +1,12 @@
+/**


Previously we were using @internxt/prettier-config, however when trying to extend it's not readable and we don't know which fields are defined and which not. In this case I added the endOfLine: 'crlf' since the project uses it but it wasn't configured, so in laptops like mine, in which I use lf by default I had all files fill of prettier and eslint "errors". Technically in modern projects lf is recommended and either option should be added to .gitattributes, but can be done in another PR.

hey, the idea of the @internxt/prettier-config is to share the same config between all the projects. That way, instead of each project having slightly different setups (like this endOfLine case), we keep everything consistent in a single place.

If something is missing or needs adjustment (like adding endOfLine: 'crlf' or revisiting the LF vs CRLF decision), I think the best approach is to update it directly in the shared config project. This way, the improvement propagates automatically to all repos instead of fixing it one by one.

In my opinion, this helps avoid config drift and keeps things much easier to maintain long-term

But for something as simple as the prettier I think it adds friction for so little benefit. For example, this is the example of prettier in windows:

/** * @see https://prettier.io/docs/configuration * @type {import("prettier").Config} */ module.exports = { arrowParens: 'always', bracketSameLine: true, bracketSpacing: true, endOfLine: 'lf', importOrder: ['^@/(.*)$', '^[./]'], importOrderParserPlugins: ['typescript', 'jsx', 'decorators-legacy'], plugins: [require.resolve('@trivago/prettier-plugin-sort-imports'), require.resolve('prettier-plugin-tailwindcss')], printWidth: 140, proseWrap: 'never', semi: true, singleQuote: true, tabWidth: 2, trailingComma: 'all', useTabs: false, };

Here we are using plugins with a tailwind plugin and sorting imports with another plugin. But maybe another project doens't use tailwind, why should that project import it? Or maybe a project breaks if it changes the imports order (that was happening on windows and currently it happens in linux). I think that trying to make it projects consistent in things that do not provide real value just slows down (that's the reason why I haven't changed the prettier config before and I've been working with those visual errors other times).

Or maybe someone updates the prettier config and now your projects breaks and you stop being able to update that dependency, etc.

yeah, I agree with you on the plugins, but maybe we could go with a mix: have a minimal shared config (just the core rules that make sense everywhere), and then let each project extend it with whatever it actually needs (like Tailwind or import sorting plugins).

That way we keep some consistency across repos without forcing things that might break or dont apply to all projects 🤔

Okey, should I add lf or crlf to the prettier-config project? My plan here was setting to crlf and in another PR maybe move to lf since it's the recommended way for multi platform projects (also adding the .gitattributes).

as it is out of this scope, maybe its better to fix and improve this prettier-config on another PR, and using LF looks the best option to me too

larryrider · 2026-04-09T13:14:36Z

.gitignore


 coverage/

-.npmrc


hey! is this intentional?

Just flagging it because .npmrc files often contain sensitive or environment-specific configuration (like auth tokens, registry URLs, etc.), and committing it to the repo can lead to security or portability issues across different environments 🤔

Hey, it's intentional. Since the @internxt/prettier package is no longer needed, all others are published in npm and don't need the .npmrc. So, to not have any issues while installing them we no longer need the .npmrc and every update will be installed from npm/yarn. I forgot to add the comment to the line, my bad. I can revert it if you think it's safer.

Just to add some context: the .npmrc we had was already pointing directly to npm, so in practice it wasn’t really affecting the Prettier setup. Also, Prettier doesnt rely on .npmrc anyway since its fetched from GitHub using its own kind of "bypass", so removing it wont change that behavior.

Yes, for me the safest approach would be to keep it ignored to avoid any accidental leaks. If you agree, I would keep it in .gitignore 👍

Just checked and true, prettier doesn't use the .npmrc file.

larryrider · 2026-04-09T13:23:30Z

.npmrc.template

@@ -1,3 +0,0 @@
-registry=https://registry.yarnpkg.com/


I think it might be better to keep the .npmrc.template 🤔
The idea of having a template is useful in case a user has a global .npmrc (for example, pointing to GitHub or any other registry), and we still want to ensure the project uses a consistent local configuration when needed.

With a .npmrc.template, each developer can create their own local .npmrc based on it, adapting things as needed while still keeping the project-level setup under control

larryrider · 2026-04-09T13:50:52Z

test/drive/storage/index.test.ts

@@ -1,5 +1,4 @@
 import { beforeEach, describe, expect, it, vi } from 'vitest';
-import { v4 } from 'uuid';


if you are going to stop using the uuid library, which it looks good to me, then it could be a good idea to remove it from dependencies too

I removed it because it wasn't in the dependencies and knip was showing me the error. It was picking it from another dependency.

CandelR

It looks fine to me, in drive-web, a few minor changes would need to be made as it uses an instanceof AppError, but I’d say it’s nothing serious and the changes are straightforward

CandelR · 2026-04-09T14:59:39Z

src/shared/types/errors.ts

  }
 }
+
+export class AxiosResponseError extends Error {


consider add tests for this new class

Done, they are tested in this file: https://github.com/internxt/sdk/pull/382/changes#diff-3fcf5dd955eaca4e092688cf0a0c18468bf478e02ef4187cefb7164cbbea4091R66. Previously it was asserting against the error.message and now it's change to match all properties. With toMatchObject we can match against the error properties but technically the objects asserted are both types of errors.

dajimenezriv-internxt added 2 commits April 9, 2026 14:36

Improve normalize error

b02a874

Update pre-commit

101e3ed

dajimenezriv-internxt self-assigned this Apr 9, 2026

dajimenezriv-internxt commented Apr 9, 2026

View reviewed changes

dajimenezriv-internxt requested review from AlexisMora, CandelR, larryrider and patricioxavier8 April 9, 2026 12:57

larryrider reviewed Apr 9, 2026

View reviewed changes

dajimenezriv-internxt requested a review from larryrider April 9, 2026 13:23

Commit

dd85a41

larryrider reviewed Apr 9, 2026

View reviewed changes

dajimenezriv-internxt requested review from larryrider and removed request for patricioxavier8 April 9, 2026 14:08

CandelR approved these changes Apr 9, 2026

View reviewed changes

Commit

c57dea1

		@@ -1,23 +1,3 @@
		import { AxiosError, AxiosResponse } from 'axios';

		export function extractAxiosErrorMessage(err: AxiosError): string {

		@@ -1,5 +1,4 @@
		import { beforeEach, describe, expect, it, vi } from 'vitest';
		import { v4 } from 'uuid';

Conversation

dajimenezriv-internxt commented Apr 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What

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!

dajimenezriv-internxt Apr 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

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!

CandelR 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!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

dajimenezriv-internxt commented Apr 9, 2026 •

edited

Loading

dajimenezriv-internxt Apr 9, 2026 •

edited

Loading