Tella Web receives old audio file name, after renaming it, when auto-upload is enabled

[LLMuser]

Expected behavior

Renaming an audio file should update the file name to the user-defined name and persist across recordings and subsequent app actions.

Actual behavior

The renamed audio file does not retain the new name. Instead, the application creates or reverts to a different (auto-generated) name, ignoring the user-defined name. This occurs whether the file is renamed before or after recording.

Steps to reproduce the problem

1. Create or select an audio file in the application.
2. Rename the audio file to a custom name.
3. Start a recording or re-open the file.
4. Observe that the file name changes to a different name generated by the application.

Additional information

• Renaming was tested both before and after recording with the same result.
• Device: Samsung (One UI 8.0)
• Android version: 16
• Tella Android app version: 1.18.1 (222)

[carohadad]

Hi @LLMuser ! thank you for reporting this! we will work on the fix. I'll let you know as soon as it's live so you could verify it's working well for you.

[LLMuser]

Short update: the new filename is not shown after renaming. But the uploaded file has the new filename. Kind of confusing...

[carohadad]

hello @LLMuser !

We have been trying to reproduce this issue and I'm a bit confused.

On your last message you said "uploaded". Can you clarify what do you mean with that? Do you have any connections enabled? Is this related to your other bug report? (for example: the audio file gets auto-uploaded to Tella Web with the new name).

If you don't have any connections enabled, the file doesn't upload, it's just saved in the Tella vault.

We tested this issue in as many devices as we couldn't reproduce it. Every time we save an audio, a new file gets generated with the correct (renamed) name and stored in the Tella vault. We wonder if this could be an issue with our UX that gets users confused because after pressing the stop button, you will see the Microphone again with a placeholder name for a new file

I recoreded this video to better explain myself.

Please let me know if I missunderstood your report!

Thank you for helping us improve Tella!
Caro from the Tella Team

[LLMuser]

Hi Caro, thanks for the follow up. I guess it´s exactly this:

We wonder if this could be an issue with our UX that gets users confused because after pressing the stop button, you will see the Microphone again with a placeholder name for a new file.

Sorry for the hassel and thanks for your great work on Tella!

[carohadad]

No problem at all! I'm happy that it's working as expected then!
We will continue talking in the other issue you submitted, but in the meantime, feel free to contact us to contact@tella-app.org with any comments, feedback or ideas to improve Tella.

And if you like the product, we always appreciate a review and recomendations. It's getting hard for us to get Tella more known and useful for the communities, any help is appreciated <3

[LLMuser]

@carohadad I´d like to reopening this issue with a narrower and more specific scope.

Summary

On Android, when an audio filename is renamed before recording, the file is still be auto-uploaded with the original auto-generated/default filename instead of the renamed one.

This is especially problematic in setups using:

• auto upload
• delete after upload / instant delete

because the local file is removed immediately after upload, so there is no later chance to correct the filename.

Scope of the issue

This is not about renaming an already recorded audio file later in the vault.

This is specifically about:

1. creating a new audio recording
2. changing the filename before starting the recording
3. stopping the recording
4. the file being auto-uploaded
5. the uploaded file appearing in Tella Web with the default/generated filename, not the renamed one

Reproduction

1. On Android, open audio recording.
2. Before starting the recording, change the proposed filename.
3. Start and stop recording.
4. Let the file auto-upload.
5. If delete-after-upload is enabled, the local copy is removed.
6. Check the uploaded file in Tella Web.

Expected

The uploaded file should use the renamed filename entered before recording.

Actual

The uploaded file uses the auto-generated/default filename instead.

Comparison

The same workflow works correctly on iOS, which suggests this is likely an Android client-side issue rather than a Tella Web/backend issue.

Likely cause from code review

Based on the current Android code, the issue appears to be in the recorder -> rename -> auto-upload handoff.

Relevant observations

• In the recorder flow, the entered name is first handled via currentRecordName and updated asynchronously after validation/uniqueness checks in the recorder UI.
• When recording stops, both recorder implementations appear to call:

MediaFileHandler.renameFile(vaultFile, recordingName.text.toString())

• However, the flow then continues using the original vaultFile object for the next steps such as:
  • onAddSuccess(vaultFile)
  • scheduleFileUpload(vaultFile)

This suggests the file may be physically/logically renamed, but the auto-upload job still receives a stale pre-rename VaultFile reference.

The same pattern appears to flow further into the upload scheduling path, where the upload/report creation uses the VaultFile object it was given.

Why this matters

For teams relying on auto-upload + immediate deletion, the filename is part of the operational workflow and evidence chain. If the Android client uploads using the wrong filename, users lose the intended naming at the moment of upload and cannot correct it afterward.

Suggested fix

After renameFile(...) returns, the recorder flow should consistently use the renamed/returned VaultFile for all subsequent actions, including:

• add success handling
• metadata attachment
• report creation
• auto-upload scheduling

instead of continuing with the original pre-rename vaultFile.

Attachments

I added some screenshots to demonstrate it.

[carohadad]

OH Thank you so much for the added context!! I know undestand it better and I'm able to work with the devs to reproduce and fix the issue. Re-opening.