Summary

Change deferment during action registration to only defer placement.

Review Request #14707 — Created Nov. 24, 2025 and updated Nov. 29, 2025, 11:06 a.m.

Information

Owner

chipx86

Repository

Review Board

Branch

release-7.1.x

Bugs

Depends On

Reviewers

Groups

reviewboard

People

Description

Actions are no longer ever deferred. Instead, placements depending on a
missing parent are now deferred.

When placing an action during registration or when resolving a deferred
placement later, any deferred placements depending on the newly-placed
action will be further resolved. This ensures that placements will
always resolve once all parents have been placed, no matter when that
occurs.

If an action is unregistered, any actions depending on it will move back
to a deferred state so they can be re-placed if the action comes back.
This is important for extensions.

Along with this, the registry has been updated to make use of
on_item_* hooks, instead of overriding register and unregister,
allowing the registry to manage when this logic occurs, taking advantage
of any locks.

Testing Done

All unit tests passed.

Verified this fixed issues with in-progress changes with actions
containing a placement that had a valid parent and a placement
that did not.

Commits

Summary	ID
Change deferment during action registration to only defer placement. When registering actions, we've historically deferred them if they depended on a parent that wasn't yet registered. With the new multi-placement actions being introduced, it's possible an action would be placed somewhere currently valid and somewhere that may never be valid (such as a legacy attachment point or one defined by an extension). When this happened, the action would never end up being registered. Actions are no longer ever deferred. Instead, placements depending on a missing parent are now deferred. When placing an action during registration or when resolving a deferred placement later, any deferred placements depending on the newly-placed action will be further resolved. This ensures that placements will always resolve once all parents have been placed, no matter when that occurs. If an action is unregistered, any actions depending on it will move back to a deferred state so they can be re-placed if the action comes back. This is important for extensions. Along with this, the registry has been updated to make use of `on_item_*` hooks, instead of overriding `register` and `unregister`, allowing the registry to manage when this logic occurs, taking advantage of any locks.	52a2a5409cfaa7fe2fe997b7805d26f881af9ebc

Summary

Change deferment during action registration to only defer placement.

When registering actions, we've historically deferred them if they depended on a parent that wasn't yet registered. With the new multi-placement actions being introduced, it's possible an action would be placed somewhere currently valid and somewhere that may never be valid (such as a legacy attachment point or one defined by an extension). When this happened, the action would never end up being registered. Actions are no longer ever deferred. Instead, placements depending on a missing parent are now deferred. When placing an action during registration or when resolving a deferred placement later, any deferred placements depending on the newly-placed action will be further resolved. This ensures that placements will always resolve once all parents have been placed, no matter when that occurs. If an action is unregistered, any actions depending on it will move back to a deferred state so they can be re-placed if the action comes back. This is important for extensions. Along with this, the registry has been updated to make use of `on_item_*` hooks, instead of overriding `register` and `unregister`, allowing the registry to manage when this logic occurs, taking advantage of any locks.

52a2a5409cfaa7fe2fe997b7805d26f881af9ebc

Issues

Description	From	Last Updated
typo: placemetn -> placement	david	Nov. 26, 2025, 12:27 a.m.
Can we add comments here to indicate that the tuple is (parent_id, attachment) and the dict is {action_id: action}?	david	Nov. 28, 2025, 4:51 p.m.
Can we include the action_id, parent_id, and attachment point in this log entry?	david	Nov. 28, 2025, 4:53 p.m.
Needs a trailing comma.	david	Nov. 28, 2025, 4:53 p.m.

flake8 passed.

JSHint passed.

Ship it!

reviewboard/actions/registry.py (Diff revision 1)
The issue has been resolved. Show all issues
```
typo: placemetn -> placement
```

Ship it!

```
Ship It!
```

Change Summary:

This is a big update that requires a re-review. It largely fixes clearing out state that remained after unregistration, which impacted unit tests semi-randomly.

Children of placements are now removed before the parent placement is processed, so that it can make decisions based on the removal of child state from caches.
Placements are removed from defer lists when they don't have children, and removed from parent defer lists when they're being unregistered.
Optimized removing of deferred placements by switching to a dict instead of scanning a list.
Removed a warning when an action is missing from by_attachment_point, because it can be removed both when the action itself is unregistered or when a parent is unregistered, and unregistering both would always result in the warning.
During population, suppressed a debug log shown when deferring an action during registration when there's a missing parent, so there's not a bunch of spurious logs at startup.
Moved to a defaultdict for deferred lists.
Fixed a typo in the docs.

Commits:

	Summary	ID
	Change deferment during action registration to only defer placement. When registering actions, we've historically deferred them if they depended on a parent that wasn't yet registered. With the new multi-placement actions being introduced, it's possible an action would be placed somewhere currently valid and somewhere that may never be valid (such as a legacy attachment point or one defined by an extension). When this happened, the action would never end up being registered. Actions are no longer ever deferred. Instead, placements depending on a missing parent are now deferred. When placing an action during registration or when resolving a deferred placement later, any deferred placements depending on the newly-placed action will be further resolved. This ensures that placements will always resolve once all parents have been placed, no matter when that occurs. If an action is unregistered, any actions depending on it will move back to a deferred state so they can be re-placed if the action comes back. This is important for extensions. Along with this, the registry has been updated to make use of `on_item_*` hooks, instead of overriding `register` and `unregister`, allowing the registry to manage when this logic occurs, taking advantage of any locks.	143686434e96a23940e8b70211ddb7e860b7fc1c
	Change deferment during action registration to only defer placement. When registering actions, we've historically deferred them if they depended on a parent that wasn't yet registered. With the new multi-placement actions being introduced, it's possible an action would be placed somewhere currently valid and somewhere that may never be valid (such as a legacy attachment point or one defined by an extension). When this happened, the action would never end up being registered. Actions are no longer ever deferred. Instead, placements depending on a missing parent are now deferred. When placing an action during registration or when resolving a deferred placement later, any deferred placements depending on the newly-placed action will be further resolved. This ensures that placements will always resolve once all parents have been placed, no matter when that occurs. If an action is unregistered, any actions depending on it will move back to a deferred state so they can be re-placed if the action comes back. This is important for extensions. Along with this, the registry has been updated to make use of `on_item_*` hooks, instead of overriding `register` and `unregister`, allowing the registry to manage when this logic occurs, taking advantage of any locks.	4b5851e8bd2ef8dddcadb7f819ff905126eacde1

Diff:

Revision 2 (+888 -312)

Show changes

	reviewboard/actions/registry.py
	reviewboard/actions/tests/test_registry.py

Checks run (2 succeeded)

flake8 passed.

JSHint passed.

reviewboard/actions/registry.py (Diff revision 2)

The issue has been resolved. Show all issues

Can we add comments here to indicate that the tuple is (parent_id, attachment) and the dict is {action_id: action}?

reviewboard/actions/registry.py (Diff revision 2)

The issue has been resolved. Show all issues

Can we include the action_id, parent_id, and attachment point in this log entry?

reviewboard/actions/registry.py (Diff revision 2)
The issue has been resolved. Show all issues
```
Needs a trailing comma.
```

Change Summary:


Improved logging.
Added information on the structure of _deferred_placements in the docs.
Added a missing trailing comma.

Commits:

	Summary	ID
	Change deferment during action registration to only defer placement. When registering actions, we've historically deferred them if they depended on a parent that wasn't yet registered. With the new multi-placement actions being introduced, it's possible an action would be placed somewhere currently valid and somewhere that may never be valid (such as a legacy attachment point or one defined by an extension). When this happened, the action would never end up being registered. Actions are no longer ever deferred. Instead, placements depending on a missing parent are now deferred. When placing an action during registration or when resolving a deferred placement later, any deferred placements depending on the newly-placed action will be further resolved. This ensures that placements will always resolve once all parents have been placed, no matter when that occurs. If an action is unregistered, any actions depending on it will move back to a deferred state so they can be re-placed if the action comes back. This is important for extensions. Along with this, the registry has been updated to make use of `on_item_*` hooks, instead of overriding `register` and `unregister`, allowing the registry to manage when this logic occurs, taking advantage of any locks.	4b5851e8bd2ef8dddcadb7f819ff905126eacde1
	Change deferment during action registration to only defer placement. When registering actions, we've historically deferred them if they depended on a parent that wasn't yet registered. With the new multi-placement actions being introduced, it's possible an action would be placed somewhere currently valid and somewhere that may never be valid (such as a legacy attachment point or one defined by an extension). When this happened, the action would never end up being registered. Actions are no longer ever deferred. Instead, placements depending on a missing parent are now deferred. When placing an action during registration or when resolving a deferred placement later, any deferred placements depending on the newly-placed action will be further resolved. This ensures that placements will always resolve once all parents have been placed, no matter when that occurs. If an action is unregistered, any actions depending on it will move back to a deferred state so they can be re-placed if the action comes back. This is important for extensions. Along with this, the registry has been updated to make use of `on_item_*` hooks, instead of overriding `register` and `unregister`, allowing the registry to manage when this logic occurs, taking advantage of any locks.	52a2a5409cfaa7fe2fe997b7805d26f881af9ebc

Diff:

Revision 3 (+902 -312)

Show changes

	reviewboard/actions/registry.py
	reviewboard/actions/tests/test_registry.py

Checks run (2 succeeded)

flake8 passed.

JSHint passed.

Ship it!

```
Ship It!
```