Skip to content

Lazily make connection with the underlying adapter - #9

Open
thetutlage wants to merge 8 commits into
0.xfrom
feat/lazy-start
Open

Lazily make connection with the underlying adapter#9
thetutlage wants to merge 8 commits into
0.xfrom
feat/lazy-start

Conversation

@thetutlage

Copy link
Copy Markdown
Member

No description provided.

thetutlage and others added 2 commits April 28, 2026 15:34
…ent and during start phase

BREAKING CHANGE: Any custom console commands relying on jobs to be registered with the queue
manager will not work. They will have to resolve the queue.manager from the container and
explicitly invoke the start method
The redis and database drivers acquired their connection when the
config provider was resolved, which happens during the provider's start
hook. Therefore, starting the app opened a connection even when nothing
used the queue. The connection is now acquired from within the adapter
factory, which the queue manager invokes on first use of the adapter.

An app that never becomes ready (for example, the codegen command)
skips the shutdown hooks, hence the eagerly opened redis connection
kept the process alive.

The driver tests run against a real redis server and an in-memory
sqlite database. The CI workflow defines the tests job inline, since a
job using the shared workflow cannot attach the redis service.
Comment thread .github/workflows/checks.yml Fixed
thetutlage and others added 6 commits August 26, 2026 14:12
…ntain permissions'

Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
An app created in the "warmup" mode never becomes ready, hence nothing
dispatches or processes jobs. Loading the jobs only discovers them for
no use and warns when there are none.

The mode is checked defensively, since the older versions of the
framework core do not have the "getMode" method.
The merge kept the "start" method patched on the queue manager and the
"initQueue" helper, whereas the 0.x branch initializes the queue manager
from the container binding and loads the jobs from the "loadJobs" method
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