observability-plugin: shared-dependency hooks do full diagnostic work on the startup path at summary level, with no opt-out

Open
  • Is something wrong?
#5,204 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
55/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
javascript, react, typescript, webpack
Domain
backend-api-design, observability, performance

Research direction

Start by tracing afterRegisterShare, initContainerShareScopeMap, resolveShare, beforeLoadShare, and afterLoadShare into recordEvent and the event notification functions; the issue does not name source files or tests. Compare the proposed opt-out and level-check approaches, then locate the existing tests for shared hooks and event reporting. Done means shared success-path work can be disabled or avoided at summary level while singleton conflict detection and shared-load failures still report correctly.

Written by the indexing model from the issue text.

Description

Versions: @module-federation/observability-plugin 2.6.2, @module-federation/runtime-core 2.9.2, browser host

What happens
  • afterRegisterShare and initContainerShareScopeMap call recordSharedRegistration once for every shared package version in every container. Each call runs createSharedRegistrationInfo, which builds the candidate list (a semver satisfies per candidate) and sanitizes strings with the URL and secret regexes. Each registration also gets a unique shared-register-N request id, so resolveTraceId creates a new trace and report for every one.
  • On every loadShare / loadShareSync, resolveShare wraps the resolver to build a full selection (candidates plus semver checks). afterLoadShare then records a success event.
  • recordEvent runs normalizeEvent, applyPhaseDuration and updateTraceMaps before it checks shouldRecordEvent. summary drops only start events, so these success events are fully recorded.
  • Every recorded event is deep-copied twice: notifyEvent copies the event and the report, then notifyReport copies the report again. Each copy is a spread followed by a recursive Object.entries clone.

All of this runs synchronously during container init and shared resolution, before the first remote renders. It runs even when nothing reads shared-registration or shared-resolution data. summary is the default level, and onEvent / onReport are commonly set for load and error telemetry.

Impact

We tested a host with dozens of shared packages and a few remotes, using 30 paired cold loads on one machine and network. Removing the success-path shared hooks shortened time to first remote render by:

  • ~25 ms (median) at native CPU speed
  • ~70 ms (median) with 2× CPU throttling

In a CPU profile, recordSharedRegistration was the largest single cost inside the plugin.

Proposals
  1. Add a factory option alongside disablePreloadHooks, e.g. disableSharedHooks, or a finer sharedAudit: 'all' | 'errors'. It would skip afterRegisterShare, initContainerShareScopeMap, resolveShare, beforeLoadShare and afterLoadShare. It would keep beforeRegisterShare (singleton version-conflict detection) and errorLoadShare (shared load failures).
  2. In recordEvent, check the level before building the event. Better still, let hooks skip building shared info when the event would be dropped.
  3. Copy the report once per event and pass the same copy to onEvent and onReport.
Workaround

runtime-core registers a hook only when its value is truthy, so wrap the plugin and clear the keys. Clear them on the apply() result as well, because it takes precedence:

const DROPPED = {
  afterRegisterShare: undefined,
  initContainerShareScopeMap: undefined,
  resolveShare: undefined,
  beforeLoadShare: undefined,
  afterLoadShare: undefined,
};
const { plugin } = createObservability(options, factoryOptions);
const { apply } = plugin;
const filtered = {
  ...plugin,
  ...DROPPED,
  apply: apply && (instance => {
    const hooks = apply(instance);
    return hooks && { ...hooks, ...DROPPED };
  }),
};

errorLoadShare still reports failures with their reason in this setup, because ensureSharedLoadContext creates the operation context when beforeLoadShare didn't run.

Related: #5110 reduces the plugin's bundle size; this issue is about runtime work on the startup path.

Dominant language
JavaScript
Stars
2.7k
Forks
441
Avg merge
2d 23h
Merged PRs (30d)
18

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from module-federation/core

All issues in module-federation/core

Similar issues

More JavaScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.