Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hot Reload Fails to Reset Timers and Class State, Causing Stale Async Behavior #16839

Open
andrewmd5 opened this issue Jan 28, 2025 · 0 comments
Labels
bug Something isn't working needs triage

Comments

@andrewmd5
Copy link

andrewmd5 commented Jan 28, 2025

What version of Bun is running?

1.2.1+ce532901c

What platform is your computer?

Darwin 24.3.0 arm64 arm

What steps can reproduce the bug?

  1. Create a TypeScript class with static state and timers (e.g., a Map of pending requests with timeouts).
  2. Run the code with bun --hot.
  3. Modify the code to add/changed timeouts (e.g., add a rejection timeout).
  4. Trigger hot reload by saving the file.

Reproduction below:

// timer-bug.ts
type PendingRequest = {
    resolve: (value: string) => void;
    reject: (reason?: Error) => void;
    timeoutId?: ReturnType<typeof setTimeout>;
};

class TimeoutSystem {
    private static pending = new Map<number, PendingRequest>();
    private static idCounter = 1;

    static createRequest(): { id: number; promise: Promise<string>; } {
        const id = this.idCounter++;
        let resolve!: (value: string) => void;
        let reject!: (reason?: Error) => void;

        const promise = new Promise<string>((res, rej) => {
            resolve = res;
            reject = rej;

            // Initial implementation (version 1)
            const timeoutId = setTimeout(() => {
                this.pending.delete(id);
                resolve("Initial response");
            }, 3000);

            this.pending.set(id, { resolve, reject, timeoutId });
        });

        return { id, promise };
    }

    // Uncomment for version 2 after first run
    /*
    static createRequest(): { id: number; promise: Promise<string> } {
      const id = this.idCounter++;
      let resolve!: (value: string) => void;
      let reject!: (reason?: Error) => void;
  
      const promise = new Promise<string>((res, rej) => {
        resolve = res;
        reject = rej;
  
        // Updated implementation with timeout
        const timeoutId = setTimeout(() => {
          this.pending.delete(id);
          resolve("Updated response");
        }, 1000);
  
        // Added rejection timeout
        const rejectionTimeoutId = setTimeout(() => {
          this.pending.delete(id);
          reject(new Error("Timeout after 500ms"));
        }, 500);
  
        this.pending.set(id, { 
          resolve, 
          reject, 
          timeoutId: rejectionTimeoutId // Store rejection timeout
        });
      });
  
      return { id, promise };
    }
    */
}

// Test execution
console.log("[INIT] Starting request...");
const { promise } = TimeoutSystem.createRequest();
promise
    .then(r => console.log("[SUCCESS]", r))
    .catch(e => console.log("[ERROR]", e.message));

The rejection timeout does not trigger until you do a full restart.

What is the expected behavior?

  • Hot reload should reset all timers and class state to reflect the updated code.
  • Newly added/changed timeouts should execute as expected.
  • Previous timers should be canceled and cleaned up.

What do you see instead?

  • Timers from the previous version persist and execute with outdated logic/durations.
  • Newly added timeouts fail to trigger.
  • Class static state becomes corrupted, mixing old and new instances.
  • Requires a full restart for timeout changes to take effect.

Additional information

Makes iterative async/timer development impossible with --hot. Forces full restarts for timeout-related changes. But you'll only figure that out after spending a few hours trying to figure out why your code that should work isn't. Ran into this twice before realizing that there is definitely a bug in Bun.

@andrewmd5 andrewmd5 added bug Something isn't working needs triage labels Jan 28, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working needs triage
Projects
None yet
Development

No branches or pull requests

1 participant