# Piccolo errore nella console dopo il caricamento riuscito di un file CSV per i tag

**URL:** <https://meta.discourse.org/t/small-error-in-the-console-after-a-successful-csv-file-upload-for-tags/283849>\
**Category:** Bug\
**Created:** [29 Ottobre 2023, 11:59pm UTC](https://meta.discourse.org/t/small-error-in-the-console-after-a-successful-csv-file-upload-for-tags/283849 "2023-10-29T23:59:38Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![Arkshine](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/arkshine/32/298682_2.png) [@Arkshine](https://meta.discourse.org/u/Arkshine)\
**Post date:** [29 Ottobre 2023, 11:59pm UTC](https://meta.discourse.org/t/small-error-in-the-console-after-a-successful-csv-file-upload-for-tags/283849/1 "2023-10-29T23:59:38Z")

</div>

![chrome_DzYBzsNlI0](https://global.discourse-cdn.com/meta/original/4X/a/8/9/a89454bed7f79345a8268ce36caa48182b0cf344.png)

Se carichi un file CSV con tag, la console visualizzerà un errore dopo un caricamento riuscito.

* * *

Ecco alcune indagini.

Il problema di fondo è essenzialmente che la modale si chiude troppo velocemente con la logica attuale.

L’errore si verifica in `uppy-upload.js`.  
Le proprietà non sono state impostate perché l’elemento (`uppy-upload`) era già stato distrutto.

Com’è possibile? `this._uppyInstance?.cancelAll();`

Per riferimento, `_reset` viene chiamato da `_allUploadsComplete`.

> <https://github.com/discourse/discourse/blob/1a78e8ec1bf4b6759893a28565f44fabeb6e68e1/app/assets/javascripts/discourse/app/mixins/uppy-upload.js#L468-L476>

Al caricamento riuscito, questo è l’ordine delle funzioni:  
`uploadDone` → `_allUploadsComplete` → [`_reset`]

> <https://github.com/discourse/discourse/blob/1a78e8ec1bf4b6759893a28565f44fabeb6e68e1/app/assets/javascripts/discourse/app/mixins/uppy-upload.js#L212-L229>

Quando viene chiamata `uploadDone`, la modale viene chiusa immediatamente.  
Ciò significa che l’elemento `uppy-upload` verrà distrutto alla fine del frame.  
[https://github.com/discourse/discourse/blob/main/app/assets/javascripts/admin/addon/components/tags-uploader.js#L22-L26](https://github.com/discourse/discourse/blob/main/app/assets/javascripts/admin/addon/components/tags-uploader.js#L22-L26)

Tornando a `this._uppyInstance?.cancelAll();`. Questo attiverà l’evento sottostante.  
Questo è il motivo per cui fallisce. A causa di `run()`, le proprietà verranno impostate _dopo_ che l’elemento è stato distrutto.

> <https://github.com/discourse/discourse/blob/1a78e8ec1bf4b6759893a28565f44fabeb6e68e1/app/assets/javascripts/discourse/app/mixins/uppy-upload.js#L259-L272>

Questa è una regressione minore. Introdotta qui:

`uppy-upload.js`

> <https://github.com/discourse/discourse/pull/16383/files#diff-34546f91be45fb6bb745e39a35038cd5875a047bc37cbd267e4c5cfba169f83aR251-R265>
>
> This PR brings the \`UppyUploadMixin\` more into line with the \`ComposerUppyUpload…\` mixin, by extending the \`ExtendableUploader\` . This also adds better tracking of and events for in progress uploads in the \`UppyUploadMixin\` for better UI interactions, and also opens up the use of \`\_useUploadPlugin\` for the mixin, so anything implementing \`UppyUploadMixin\` can add extra uppy preprocessor plugins as needed.
> 
> This has been done as part of work on extracting uploads out of the chat composer. In future, we might be able to do the same for \`ComposerUppyUpload\`, getting rid of that mixin to standardise on \`UppyUploadMixin\` and have a separate \`composer-uploads\` component that lives alongside \`composer-editor\` like what we are doing in https://github.com/discourse/discourse-chat/pull/764

> <https://github.com/discourse/discourse/pull/18393/files#diff-34546f91be45fb6bb745e39a35038cd5875a047bc37cbd267e4c5cfba169f83a>
>
> This commit addresses issues around starting new uploads in a composer etc. when… one or more uploads are already processing or uploading. There were a couple of issues:
> 
> 1. When all preprocessors were complete, we were not resetting \`completeProcessing\` to 0, which meant that \`needProcessing\` would never match \`completeProcessing\` if a new upload was started.
> 2. We were relying on the uppy "complete" event which is supposed to fire when all uploads are complete, but this doesn't seem to take into account new uploads that are added. Instead now we can rely on our own \`inProgressUploads\` tracker, and consider all uploads complete when there are no \`inProgressUploads\` in flight
> 
> This is difficult to test for in JS since it involves the upload lifecycle and AJAX calls, so tests are omitted.

`tags-upload.js`

> <https://github.com/discourse/discourse/pull/18292/files#diff-a4dc7755f41639b3d0bfceaca433e948683daf16bee1776f2830e5bc0e49f122>

Possibili soluzioni funzionanti:

- Chiudere la modale un po’ più tardi

```js
  uploadDone() {
    this.refresh();
    this.dialog
      .alert(I18n.t("tagging.upload_successful"))
      .finally(() => this.closeModal());
  }

```

- Spostare il controllo fuori dal ciclo `run()`.

```js
    this._uppyInstance.on("file-removed", (file, reason) => {
      // gestiamo specificamente l'evento cancel-all, quindi non è necessario
      // fare nulla qui. questo evento viene anche attivato quando alcuni file
      // vengono gestiti da un gestore di caricamento
      if (reason === "cancel-all") {
        return;
      }

      run(() => {

```

Non sono sicuro se ci sia una soluzione migliore. Quindi, sto postando qui.  
È un testo lungo per un problema minore non bloccante, ma non era inizialmente evidente. 😄