Summary

Delay database access in ExtensionManager.

Review Request #14767 — Created Jan. 8, 2026 and submitted Feb. 26, 2026, 8:56 a.m.

Information

Owner

david

Repository

Djblets

Branch

release-6.x

Bugs

Depends On

Reviewers

Groups

djblets

People

Description

For production code, the ExtensionManager instance is typically
created as part of application init, because it needs to contribute to
URLs. This was causing database access to occur before apps were fully
ready, spewing warnings.

This change adds a delay_init parameter to the ExtensionManager
constructor. When this is set to True, we hold off on creating the
GenerationSynchronizer until later. For unit tests, we pass this in as
False. For real code, we pass this in as True and then the load()
method will end up finishing the initialization.

Testing Done


Ran unit tests.
Ran the Review Board devserver (with some matching changes to that

  codebase) and saw no more errors about early database access.

Commits

Summary	ID
Delay database access in ExtensionManager. For production code, the `ExtensionManager` instance is typically created as part of application init, because it needs to contribute to URLs. This was causing database access to occur before apps were fully ready, spewing warnings. This change adds a `delay_init` parameter to the `ExtensionManager` constructor. When this is set to `True`, we hold off on creating the `GenerationSynchronizer` until later. For unit tests, we pass this in as `False`. For real code, we pass this in as `True` and then the `load()` method will end up finishing the initialization. Testing Done: - Ran unit tests. - Ran the Review Board devserver (with some matching changes to that codebase) and saw no more errors about early database access.	lwzvyznkkpxoyssqqvlslkpxqoxymuzu

Summary

Delay database access in ExtensionManager.

For production code, the `ExtensionManager` instance is typically created as part of application init, because it needs to contribute to URLs. This was causing database access to occur before apps were fully ready, spewing warnings. This change adds a `delay_init` parameter to the `ExtensionManager` constructor. When this is set to `True`, we hold off on creating the `GenerationSynchronizer` until later. For unit tests, we pass this in as `False`. For real code, we pass this in as `True` and then the `load()` method will end up finishing the initialization. Testing Done: - Ran unit tests. - Ran the Review Board devserver (with some matching changes to that codebase) and saw no more errors about early database access.

lwzvyznkkpxoyssqqvlslkpxqoxymuzu

Issues

Description	From	Last Updated
Should we mention somewhere in the docstrings that if delay_init=True, the caller has to make sure to call load()?	maubin	Feb. 11, 2026, 11:32 a.m.
We should mention in here too that this will be required in Djblets 8.0+.	maubin	Feb. 11, 2026, 11:31 a.m.

flake8 passed.

JSHint passed.

The issue has been dropped. Show all issues

Should we mention somewhere in the docstrings that if delay_init=True, the caller has to make sure to call load()?

david Feb. 11, 2026, 11:33 a.m.

I don't think we need to. load() already needs to be called during app initialization.

djblets/extensions/manager.py (Diff revision 1)

The issue has been resolved. Show all issues

We should mention in here too that this will be required in Djblets 8.0+.

Commits:

	Summary	ID
	Delay database access in ExtensionManager. For production code, the `ExtensionManager` instance is typically created as part of application init, because it needs to contribute to URLs. This was causing database access to occur before apps were fully ready, spewing warnings. This change adds a `delay_init` parameter to the `ExtensionManager` constructor. When this is set to `True`, we hold off on creating the `GenerationSynchronizer` until later. For unit tests, we pass this in as `False`. For real code, we pass this in as `True` and then the `load()` method will end up finishing the initialization. Testing Done: - Ran unit tests. - Ran the Review Board devserver (with some matching changes to that codebase) and saw no more errors about early database access.	lwzvyznkkpxoyssqqvlslkpxqoxymuzu
	Delay database access in ExtensionManager. For production code, the `ExtensionManager` instance is typically created as part of application init, because it needs to contribute to URLs. This was causing database access to occur before apps were fully ready, spewing warnings. This change adds a `delay_init` parameter to the `ExtensionManager` constructor. When this is set to `True`, we hold off on creating the `GenerationSynchronizer` until later. For unit tests, we pass this in as `False`. For real code, we pass this in as `True` and then the `load()` method will end up finishing the initialization. Testing Done: - Ran unit tests. - Ran the Review Board devserver (with some matching changes to that codebase) and saw no more errors about early database access.	lwzvyznkkpxoyssqqvlslkpxqoxymuzu

Diff:

Revision 2 (+132 -24)

Show changes

	djblets/extensions/manager.py
	djblets/extensions/testing/testcases.py
	djblets/extensions/tests/test_extension_manager.py
	djblets/webapi/tests/test_oauth2_scopes.py
	djblets/webapi/tests/test_root_resource.py

Checks run (2 succeeded)

flake8 passed.

JSHint passed.

Ship it!

```
Ship It!
```

Status:: Completed
Change Summary:: Pushed to release-6.x (f6a4a3b)