feat: add CompositeRouterHook for multi-hook composition#19
feat: add CompositeRouterHook for multi-hook composition#19JhiNResH wants to merge 2 commits intoerc-8183:mainfrom
Conversation
Routes beforeAction/afterAction to up to 10 plugin hooks in priority order. - beforeAction: any plugin revert blocks the action - afterAction: try/catch so failures don't block job completion - Admin: addPlugin/removePlugin/enable/disable/setPriority Solves the single-hook limitation of ERC-8183.
…, extension points - Add per-job hook lists (mapping jobId => address[]) - Add three-tier hook resolution: per-job > template > global fallback - Add template system for reusable hook configurations - Add virtual _beforeRoute/_afterRoute extension points for inheritance - Add _validateSubHook: whitelist + ERC165 checks - Add ReentrancyGuardTransient on beforeAction/afterAction - Add getJob() passthrough view - Add hooksNotLocked/onlyJobClient modifiers - Fix: initialize() validates owner_ != address(0) - Fix: applyTemplate() validates template.length <= maxHooksPerJob - Fix: dead error CompositeRouterHook__TooManyJobHooks removed - Add nonReentrant to beforeAction/afterAction - Add docs/composite-router-hook.md Audited with Trail of Bits audit-context-building + Pashov parallel scan. All MEDIUM/HIGH findings resolved before push.
|
hey @JhiNResH some update on the hook direction for ERC-8183. For hooks here, we have a few principles to follow: extend the functionality of ERC-8183, stay as a useful lego block on top of 8183, keep it neutral and template-like, keep it light enough for lightweight or AI-assisted audit, and include explicit audit labelling. I think the router direction is valid, but at this point this PR is overlapping too much with #21, and #21 is the simpler and better fit for the repo as the first router primitive. So my preference would be to keep #21 as the router path we move forward with, not merge this version as-is, and if there are still ideas here that matter, like templates or global defaults, please bring those back later as a much smaller follow-up on top of the simpler router. I think that would give us one clear canonical router example instead of two competing ones. What do you think? Maybe you can take a look and see if we can contribute to the same one? |
|
Makes sense — #21 is a cleaner base. Closing this. The one piece I'd want to bring back: global default plugins (hooks that run for every job without per-job config). Useful when all jobs share the same pipeline (e.g. trust gate → trust update → attestation) — zero per-job setup, zero extra gas. Happy to open a small follow-up PR on top of #21 once it merges. ~200 lines, just the plugin registry + fallback in resolve logic. |
|
Superseded by #21 — will follow up with global plugin layer as a separate PR. |
github-project-automation
bot
moved this from Todo
to Done
in Hook Implementation Contributions
2 participants
CompositeRouterHook
Composite
IACPHookthat chains multiple plugin hooks in priority order. Solves the single-hook limitation of ERC-8183 by routingbeforeActionandafterActionto N plugins (max 10, gas-bounded).Behavior
beforeAction: any plugin revert blocks the actionafterAction: try/catch so failures don't block job completionaddPlugin/removePlugin/enable/disable/setPriorityThis is a neutral router primitive — no vendor-specific implementations bundled.
Splits off from #13 as requested.