#Your request couldn't be completed. Try again later in cron

1 messages · Page 1 of 1 (latest)

grim field
#

getting this error Your request couldn't be completed. Try again later in my cron function

white magnetBOT
#

Hi @grim field. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:

#

The error message "Your request couldn't be completed. Try again later" is a generic internal error in Convex that can occur for several reasons. In the context of a cron job or scheduled function, it typically indicates one of the following:

1. Memory or Resource Limits

If your cron job triggers an action (especially one using the Node.js runtime), it may be hitting memory limits. Even if the reported memory usage seems below the 512MB limit, the process may be killed if it spikes suddenly [Running into Your request]. For example, processing large files or complex data transformations can cause the execution to be terminated abruptly with this error [Running into Your request].

2. Transient Errors in Actions

Unlike mutations, actions are not automatically retried by Convex because they may have side effects (like sending an email or calling a third-party API) [Functions > Actions]. If a cron job executes an action that fails due to a transient network issue or an internal timeout, it will result in a failure for that specific run [Scheduling > Scheduled Functions].

#

3. Deployment or "Locked" State

In some cases, this error appears if the deployment environment is in a "locked" or inconsistent state, often during heavy database operations like clearing large tables. If the CLI or dashboard also returns this error when you try to interact with the deployment, it may require some time to recover or, in extreme cases during development, recreating the dev environment [Convex is locked].

#

Recommended Solutions

  • Use the Workpool Component: For reliable execution of actions, consider using the @convex-dev/workpool component. It allows you to enqueue work with configurable retry logic and parallelism limits, which is safer than calling an unreliable action directly from a cron [Components > Workpool].
  • The "Rescheduler" Pattern: Instead of having a cron call an action directly, have the cron call a mutation. The mutation can then schedule the action using ctx.scheduler.runAfter(0, ...). This ensures the cron's "workflow" (the scheduling of the next run) remains reliable even if the action itself fails [Configure Cron Jobs].
  • Check Runtime: If your cron function is hitting memory limits, check if you are using "use node". Some users have reported that removing or adjusting Node-specific code resolved unexpected 500 errors [Your request couldn't].
  • Action Retrier: You can use the @convex-dev/action-retrier component to wrap unreliable logic in a retry loop until it succeeds [Automatically Retry Actions].

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

#

@grim field Kapa.ai is still learning and improving, please let me know how I did by reacting below.

grim field
#

@white magnet how can i debug which one of these issues it is

white magnetBOT
#

Let me check the knowledge base for you again. One moment! :books:

#

To debug the "Your request couldn't be completed" error in your Convex cron functions, you should use the following diagnostic steps based on the provided documentation:

1. Locate the Request ID

Every function execution in Convex is assigned a unique Request ID. When an error occurs, the exception message usually includes this ID in the format [Request ID: <request_id>] [Finding relevant logs by Request ID].

  • Action: Copy this ID and paste it into the search bar on the Logs page in your Convex dashboard. This will filter all activity to just that specific execution, allowing you to see logs that occurred immediately before the crash [Dashboard logs page].

2. Check the Scheduler Status

If your cron jobs are not running at all or are delayed, check the Health page in the Convex dashboard.

  • Scheduler Status Card: This shows if the scheduler is "Overdue." If it is, it means you have too many scheduled tasks for the system to keep up with, which can lead to execution failures [Scheduler Status].
#

3. Add Diagnostic "Footprint" Logs

Because the error "Your request couldn't be completed" is often a result of the process being killed (e.g., due to memory exhaustion), standard error logs might not appear.

  • Memory Benchmarking: If you suspect a memory issue, manually add console.log statements throughout your function to track progress and memory usage (if using Node.js) [Discord support thread: Your request couldn't be completed].
  • Execution Progress: Log a unique string at the very beginning and at several checkpoints in your function. If the logs stop abruptly before the final checkpoint without a standard JavaScript error, it confirms a hard crash or timeout [Observing your app in production].

4. Use Log Streams for Historical Data

The Convex dashboard only preserves a limited history of logs. if your cron runs at odd hours and fails, you might miss the logs.

  • Log Streaming: Set up an integration with Axiom or Datadog. This allows you to retain historical logs indefinitely and use more powerful filtering to find patterns in when the cron fails [Log Streams: Common uses].
  • Axiom Query: You can query for specific component failures if you use the Workpool component:
    ['your-dataset']
| where parsed_message["component"] == "workpool" and parsed_message["event"] == "report"
| summarize max_backlog = max(toint(parsed_message["backlog"]))
    [Monitoring the workpool]
#

5. Verify CLI Output

During development, run npx convex logs in your terminal. This streams logs in real-time and can sometimes capture more verbose output than the dashboard during a crash [Via the CLI].

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: