[Bug]: Recorded Podcast Wiped Out and Deleted when Navigating Back from Preview Player

[santoshsingampalli11-hub]

In
PodcastRecorder.tsx
, a useFocusEffect hook is defined that triggers handleUpload() every time the screen comes into focus.

However, handleUpload() resets the entire recording state (setting filePath to null and uiState to idle) and deletes the recording from local storage (await unlinkFile()).

The issue: When a user records a podcast and navigates to the PodcastPlayer screen to preview it, navigating back to PodcastRecorder causes the screen to refocus. This fires the useFocusEffect, which instantly triggers handleUpload(), wiping the recorded podcast and deleting the local file. The user is forced to record the podcast again.

Lines causing the bug:

typescript

useFocusEffect(
useCallback(() => {
handleUpload(); // Fires on every screen focus, destroying existing recording data
}, []),
);
Expected behavior:

The useFocusEffect should not unconditionally clear recording data on focus.
Wiping/resetting the recording data should only happen when explicitly requested (e.g., when clicking "Retry" or after a successful upload), or only on screen unmount/mount.

[github-actions]

Thank you for creating this issue! We'll look into it as soon as possible. Your contributions are highly appreciated! 😊

---

🤖 Assignment Guidelines

To get assigned to this issue, simply leave a comment requesting assignment.
The AI bot will automatically assign you if you meet the following eligibility criteria:

1. You do not currently have any other active assigned issues in this repository.
2. If you were previously assigned an issue, you must have submitted a Pull Request for it before requesting a new one.

[santoshsingampalli11-hub]

/assign

[github-actions]

This issue has been triaged as a frontend task (level:critical), but requires maintainer review. cc @SB2318

Expected Effect & Scope: The issue clearly describes a critical bug in the podcast recording feature where navigating back from the preview screen causes the recorded podcast to be deleted. It provides clear reproduction steps, expected behavior, and relevant code snippets. This is a frontend-mobile bug affecting user-generated content, warranting a critical difficulty level and escalation to maintainers.

[AbhishekNagar07]

/assign

[dhanashreehingnekar28]

Hey @SB2318, I went through this flow on the live app and was able to reproduce and understand the root cause.

Description

When a user records a podcast and navigates to the Preview Player screen, then presses back, the recorded audio gets wiped out / deleted instead of being preserved. This means the user loses their recording entirely and has to start over — a frustrating experience, especially for longer recordings.

Possible Cause

• The recorded file URI is most likely stored only in local component state (useState) inside the recording screen, rather than being lifted to a shared context or passed via navigation params
• React Navigation likely unmounts the previous screen's state on back navigation, and if there's a useEffect cleanup function that deletes the temp audio file from device storage, the actual file gets removed — not just the UI reference
• There may be no persistence layer (e.g., AsyncStorage or a dedicated RecordingContext) holding onto the recording across screen transitions

Proposed Fix

• Persist the recorded file URI and metadata in a parent-level context (e.g., RecordingContext) or pass it via navigation route params, so it survives the back navigation
• Guard the cleanup logic — only delete the temp recording file when the user explicitly taps Discard or Re-record, not on every unmount
• Add a confirmation dialog ("Discard this recording?") before navigating back from the Preview Player, preventing accidental data loss

Expected Outcome

• Users can navigate back from the Preview Player without losing their recorded podcast
• The recording persists in state until the user explicitly discards it
• Improves overall reliability and trust in the podcast recording feature

I'd love to take this up — happy to get assigned and dig into the actual recording/preview components to pinpoint the exact file and submit a fix soon!

[desireddymohithreddy0925]

Greetings @SB2318 ,

I would like to work on this issue under GSSoC 2026.

I understand that the current implementation in PodcastRecorder.tsx uses useFocusEffect to call handleUpload() every time the screen gains focus. This unintentionally resets the recording state and deletes the locally stored audio file, causing users to lose their recorded podcast when navigating back from the preview screen.

I plan to work on the following:

1. Fixing the useFocusEffect behavior:

   • Remove the unconditional call to handleUpload() on every focus event
   • Ensure recording data is not cleared automatically when the screen regains focus

2. Refactoring state reset logic:

   • Prevent automatic resetting of filePath and uiState to idle on focus
   • Ensure unlinkFile() is not triggered unless explicitly required

3. Introducing proper lifecycle handling:

   • Move cleanup logic to explicit user actions such as:
     • "Retry Recording"
     • "Discard Recording"
     • Successful upload completion
   • Alternatively, restrict cleanup to screen unmount instead of focus

4. Preserving user recording flow:

   • Ensure navigation to PodcastPlayer and back does not delete existing recording
   • Maintain recording state until user explicitly chooses to reset it

5. Preventing data loss regression:

   • Add safeguards to ensure recorded audio is not deleted unintentionally
   • Verify that local file deletion only happens after confirmed upload or explicit discard

6. Testing:

   • Validate navigation flow between PodcastRecorder and PodcastPlayer
   • Ensure recording persists when navigating back
   • Verify cleanup only occurs on intended user actions

I will ensure the fix preserves user recordings, prevents accidental data loss, and improves the navigation experience without breaking existing upload logic.

Kindly assign this issue to me if possible.

Thank you!

[Divyax13]

Hello @SB2318

I have reviewed this issue and would like to work on it under GSSoC 2026.

I plan to investigate the navigation flow between the recording and preview screens to identify why the recorded podcast data is being lost when navigating back. After identifying the root cause, I will implement a fix to ensure recordings are preserved correctly and verify that the user experience remains consistent across different navigation scenarios.

Could you please assign this issue to me?

Thank you for your consideration.