Problem Description

This problem asks you to implement a promisify function that converts callback-based functions into promise-based functions.

The function promisify takes a single parameter fn, which is a callback-based function with a specific signature:

• The first parameter of fn is always a callback function
• Any additional parameters are the actual arguments for the operation

The callback function itself follows the Node.js convention:

• First parameter: the result data (when successful)
• Second parameter: the error (when an error occurs)

Your promisify function should return a new function that:

• Takes the same arguments as the original function (except the callback)
• Returns a Promise instead of using callbacks
• The Promise resolves with the data if the callback receives data without an error
• The Promise rejects with the error if the callback receives an error

For example, given a callback-based function like:

function sum(callback, a, b) {
  if (a < 0 || b < 0) {
    const err = Error('a and b must be positive');
    callback(undefined, err);
  } else {
    callback(a + b);
  }
}

After promisification, you can use it like:

const promisifiedSum = promisify(sum);
promisifiedSum(2, 3).then(result => console.log(result)); // 5
promisifiedSum(-1, 3).catch(error => console.log(error)); // Error: a and b must be positive

The key challenge is to properly wrap the callback-based function in a Promise constructor, ensuring that the callback's success and error cases are correctly mapped to Promise resolution and rejection.

Intuition

The core insight is that we need to bridge two different asynchronous patterns: callbacks and Promises. Both handle asynchronous operations, but in fundamentally different ways.

Think about what happens in a callback-based function: it performs some operation and then calls a callback with the result. In the Promise world, we want to capture that same result but deliver it through Promise resolution or rejection.

The key realization is that we can use the Promise constructor, which gives us resolve and reject functions. We can create our own callback function that will be passed to the original function fn. When this callback gets invoked by fn, we decide whether to resolve or reject the Promise based on whether an error was passed.

Here's the mental model:

1. When the promisified function is called, we create a new Promise
2. Inside this Promise, we call the original callback-based function fn
3. We provide fn with a custom callback that acts as a "translator"
4. This translator callback checks if an error was passed:
   • If there's an error (second parameter), we reject the Promise
   • If there's no error, we resolve the Promise with the data (first parameter)

The pattern (data, error) => { if (error) reject(error); else resolve(data); } is the bridge between the two worlds. It takes the callback convention and maps it to Promise behavior.

We wrap everything in a function that returns async function(...args) to ensure we return a new function that accepts the same arguments as the original (minus the callback), preserving the original function's interface while changing its asynchronous mechanism from callbacks to Promises.

Solution Approach

The implementation follows a higher-order function pattern where promisify returns a new function that wraps the original callback-based function.

Let's break down the implementation step by step:

1. Function Signature Definition:

   function promisify(fn: CallbackFn): Promisified

   The function takes a callback-based function and returns a promisified version.

2. Return a New Function:

   return async function (...args) { ... }

   We return a new function that accepts any number of arguments using the rest parameter ...args. This preserves the flexibility of the original function's argument list.

3. Create and Return a Promise:

   return new Promise((resolve, reject) => { ... })

   Inside the returned function, we create a new Promise. The Promise constructor gives us resolve and reject functions to control the Promise's outcome.

4. Call the Original Function with a Custom Callback:

   fn(
       (data, error) => {
           if (error) {
               reject(error);
           } else {
               resolve(data);
           }
       },
       ...args
   );

   We invoke the original function fn with:

   • A custom callback function as the first argument
   • All the original arguments spread using ...args

5. The Callback Bridge Logic: The custom callback (data, error) => { ... } serves as the bridge between callback and Promise patterns:

   • It receives data (the result) and error parameters
   • If error is truthy, it rejects the Promise with that error
   • If error is falsy/undefined, it resolves the Promise with the data

The beauty of this solution is that it's generic enough to work with any callback-based function that follows the standard Node.js callback convention. The spreading of arguments (...args) ensures that functions with varying numbers of parameters can all be promisified using the same implementation.

Example Walkthrough

Let's walk through a concrete example to see how the promisify function transforms a callback-based function.

Original callback-based function:

function multiply(callback, x, y) {
  if (y === 0) {
    callback(undefined, Error('Cannot multiply by zero'));
  } else {
    callback(x * y);
  }
}

Step 1: Apply promisify

const promisifiedMultiply = promisify(multiply);

This returns a new function that accepts (x, y) instead of (callback, x, y).

Step 2: Call the promisified function

promisifiedMultiply(4, 5)

Step 3: Inside the promisified function When we call promisifiedMultiply(4, 5), here's what happens internally:

1. The arguments [4, 5] are captured via ...args
2. A new Promise is created
3. Inside the Promise constructor, we call the original multiply function:

   multiply(
     (data, error) => {
       if (error) reject(error);
       else resolve(data);
     },
     4, 5  // spread from ...args
   )

Step 4: Execution of the original function The multiply function runs with:

• First parameter: our custom callback
• Second parameter: 4
• Third parameter: 5

Since y !== 0, it executes callback(4 * 5), which means our custom callback receives:

• data = 20
• error = undefined

Step 5: Promise resolution Our custom callback checks:

• Is error truthy? No (it's undefined)
• So we execute resolve(20)

Final result:

promisifiedMultiply(4, 5).then(result => console.log(result)); // Outputs: 20

Error case example:

promisifiedMultiply(4, 0)

This time multiply calls callback(undefined, Error('Cannot multiply by zero')), so:

• data = undefined
• error = Error('Cannot multiply by zero')
• Our callback executes reject(error)
• The Promise rejects with the error

promisifiedMultiply(4, 0).catch(err => console.log(err.message)); 
// Outputs: "Cannot multiply by zero"

Solution Implementation

Time and Space Complexity

Time Complexity: O(1) for the promisify function itself, and O(T) for the execution of the returned async function, where T is the time complexity of the original callback function fn.

The promisify function simply returns a new function wrapper without performing any iterations or recursive operations, making it a constant time operation. When the returned async function is invoked, it creates a Promise and calls the original function fn once. The time complexity depends entirely on what the original callback function does internally.

Space Complexity: O(1) for the promisify function, and O(S + A) for the returned async function, where S is the space used by the original callback function fn and A is the space needed to store the args array.

The promisify function itself only creates and returns a function reference, using constant space. When the returned async function executes, it allocates space for:

• The Promise object and its internal state
• The closure that captures the resolve and reject functions
• The spread args array (which has O(A) space where A is the number of arguments)
• Any additional space required by the original callback function fn

The space complexity is dominated by the arguments array and whatever space the original callback function requires for its execution.

Common Pitfalls

1. Incorrect Callback Parameter Order

One of the most common mistakes is misunderstanding the callback parameter order. Many developers assume the error comes first (Node.js convention), but this problem specifically states that the callback receives (data, error) - data first, error second.

Incorrect Implementation:

def callback_handler(error: Optional[str], data: Any) -> None:  # Wrong order!
    if error:
        future.set_exception(Exception(error))
    else:
        future.set_result(data)

Solution: Always verify the callback signature in the problem statement. In this case, ensure your callback handler accepts (data, error) in that specific order.

2. Not Handling Synchronous Exceptions

The current implementation doesn't catch exceptions that might be thrown synchronously by the original function before it even calls the callback.

Problem Scenario:

def buggy_function(callback, value):
    if value < 0:
        raise ValueError("Value must be positive")  # Synchronous exception!
    callback(value * 2, None)

Solution: Wrap the function call in a try-except block:

async def promisified_function(*args: Any) -> Any:
    loop = asyncio.get_event_loop()
    future = loop.create_future()
  
    def callback_handler(data: Any, error: Optional[str] = None) -> None:
        if error:
            future.set_exception(Exception(error))
        else:
            future.set_result(data)
  
    try:
        fn(callback_handler, *args)
    except Exception as e:
        future.set_exception(e)
  
    return await future

3. Callback Called Multiple Times

Some callback-based functions might incorrectly call the callback multiple times. The Future/Promise can only be resolved once, and subsequent calls will cause errors.

Problem Example:

def flaky_function(callback, value):
    callback(value, None)
    callback(value * 2, None)  # Second call - will cause issues!

Solution: Add a guard to ensure the Future is only set once:

def callback_handler(data: Any, error: Optional[str] = None) -> None:
    if future.done():  # Check if already resolved
        return
  
    if error:
        future.set_exception(Exception(error))
    else:
        future.set_result(data)

4. Memory Leaks with Never-Calling Callbacks

If the original function never calls the callback (due to a bug or design), the Future will never resolve, potentially causing memory leaks or hanging await statements.

Solution: Add a timeout mechanism:

async def promisified_function(*args: Any) -> Any:
    loop = asyncio.get_event_loop()
    future = loop.create_future()
  
    def callback_handler(data: Any, error: Optional[str] = None) -> None:
        if error:
            future.set_exception(Exception(error))
        else:
            future.set_result(data)
  
    fn(callback_handler, *args)
  
    # Add timeout protection (adjust timeout as needed)
    try:
        return await asyncio.wait_for(future, timeout=30.0)
    except asyncio.TimeoutError:
        raise TimeoutError("Callback was never invoked")