Skip to content

Use perform_now in test inline! mode - #176

Merged
alachaum merged 6 commits into
keypup-io:masterfrom
alachaum:invoke-middlewares-in-oneoff-executions
Jul 13, 2026
Merged

Use perform_now in test inline! mode#176
alachaum merged 6 commits into
keypup-io:masterfrom
alachaum:invoke-middlewares-in-oneoff-executions

Conversation

@alachaum

@alachaum alachaum commented Jul 10, 2026

Copy link
Copy Markdown
Member

Originally raised in: #173

The test inline! mode is expected to run jobs immediately. The problem is that this immediate execution is implemented in the create task action on the backend (MemoryTask), which is invoked while enqueuing the job.

Since the job is executed while being enqueued, the server middlewares run inside the client middlewares. This means the client middleware may leave dangling locks that the server middlewares would normally clean, thus preventing successive jobs from running in the case of the unique_job extension.

Here is a typical example:

Cloudtasker::Testing.inline! do
  TestUniqueJobWorker.perform_async(1, 2)
  TestUniqueJobWorker.perform_async(1, 2)
end
# Actual: [[1, 2]]            (second job is rejected due to dangling locks)
# Expected:  [[1, 2], [1, 2]]

This PR addresses this issue by doing the following:

  1. Ensure perform_now runs the client middlewares on top of the server middlewares. This ensures the full worker lifecycle is respected.
  2. Stop implementing the inline! execution in the create action of the backend (MemoryTask)
  3. Instead, rewire perform_async to perform_now when test inline! mode is enabled

lovitt and others added 3 commits July 13, 2026 11:37
inline! is meant to run an enqueued job as the real server would. These
specs pin three properties that hold when inline execution happens at
the universal backend point (Backend::MemoryTask.create), through which
every enqueue path funnels:

- Execution coverage: perform_async, perform_at/perform_in, the instance
  #schedule method, and batch children (enqueued via #schedule) all run.
- Error hooks: a raising job triggers the on_error hook, like the server
  path does via WorkerHandler.with_worker_handling.
- Context fidelity: the worker runs with a task_id, as assigned by the
  backend and read by app logging/instrumentation.

Only perform_async had integration coverage; the batch spec drains a
fake! queue manually rather than running inline!. Pinning these guards
against a refactor that relocates inline execution onto a narrower path.
@alachaum
alachaum merged commit 5caa71a into keypup-io:master Jul 13, 2026
71 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants