You’re right about how ODC Events behave in general—but the key detail is where and how your handler is being executed.

From the error:

OS-BERT-ELR-61302 - Error executing action. Running this action's custom code has exceeded the timeout limit of 95 seconds.

this looks like a server action timeout (synchronous execution), not an asynchronous event handler execution.

1. Events vs. Server Actions in ODC

• Events in ODC are:

  • Triggered inside server-side logic of an app.
  • Put on an event queue.
  • Then handled asynchronously by event handlers, with:
    • Up to 100 handlers in parallel.
    • 2‑minute timeout per handler.
    • Up to 10 retries with exponential backoff if the handler fails or times out. Events in ODC

• Server actions called directly from UI/client actions:

  • Have a much lower timeout (e.g., 60–95 seconds depending on call path).
  • Run synchronously (user waits).
  • Do not have automatic retries.

Your error strongly suggests that Event_UploadPDF (or code inside it) is being executed as a normal server action on a synchronous request, not as an asynchronous event handler instance.

2. Why your event handler isn’t being retried

The automatic retry behavior applies only to event handler executions started by the Event queue, not to:

• A server action that:
  • Is called directly from a screen/client action.
  • Or is being executed as part of some synchronous request.

In that case, when the handler (or its custom code) exceeds the timeout, the platform aborts the request and throws the timeout error, without retry, because from the platform’s perspective it’s just a long-running synchronous server call.

So, although the logic is inside an “event handler” module/action, if it’s being invoked like a regular server action as part of a request, the event runtime / event queue is not involved, and therefore no event retries occur. Events in ODC

3. How to get the real asynchronous behavior (with retries)

To leverage event semantics and automatic retries:

1. Trigger an Event from a short server action:

   • From your upload flow:
     • Save the PDF (or its metadata/path) quickly.
     • Trigger an Event with a small payload (e.g., FileId, UserId, etc.).
   • That server action should finish well under the 60–95 second client timeout.

2. Move the heavy processing into the Event handler:

   • The Event_UploadPDF handler should:
     • Load the file by ID.
     • Process it (parse, update multiple records, etc.).
   • This handler will then run in the Event processing engine, with:
     • Up to 2 minutes timeout.
     • Automatic retries (up to 10 times) on timeout or exception, with exponential backoff. Events in ODC

3. Ensure you’re not calling the handler synchronously:

   • Do not call Event_UploadPDF directly from UI/client actions.
   • It should only be executed as a handler for the Event.

4. Practical pattern for your case (Upload PDF)

• Client/UI flow:

  • User uploads PDF.
  • Client calls a short server action:
    • Stores binary (e.g., in an entity or object storage).
    • Triggers Event_UploadPDF with a small payload (record ID, etc.).
    • Returns immediately to the user (maybe show “Processing in background…”).

• Event handler logic (Event_UploadPDF):

  • Runs asynchronously (user does not wait).
  • Retrieves the file, processes it.
  • If it times out or throws, ODC:
    • Aborts this run.
    • Requeues and retries automatically (up to 10 times, with backoff). Events in ODC

If you structure it this way and still see OS-BERT-ELR-61302, it likely means that:

• The handler execution itself is exceeding the 2‑minute event timeout, or
• You still have some part of the code being executed synchronously (e.g., shared server action that is invoked both as handler and directly).

In that case, you may need to further split the processing into smaller units (chunking records, multiple smaller runs) so each handler execution stays within the timeout window.

Summary:
ODC will only auto‑retry when your code is executed as an actual event handler instance from the event queue. If the same logic is being run as a normal synchronous server action (which your error indicates), it’s subject to server action timeout limits and won’t be retried. Trigger a lightweight Event from your upload flow and place the heavy PDF processing exclusively in the event handler to get the asynchronous + retry behavior.

The error isn’t the event handler’s own timeout. It’s the 95 seconds limit for external logic (custom code), and that limit is the same inside an event handler. So your handler most likely did run from the event queue.

About the retry: if your handler flow has an exception handler (AllExceptions or similar) that catches this error, the handler finishes normally from the platform’s point of view, so there is nothing to retry. That’s the first thing I would check.

If you want a retry you control, keep a status and an attempt counter per document. When you catch the timeout, increase the counter and trigger the event again, or let a timer pick up the failed ones, until it reaches a max number of attempts. After that, mark it as failed so someone can look at it.