In a forked child process, only the forking thread survives. Mutexes
and condition variables are copied without ownership tracking (orphan
locks), the scheduler thread reference is dead, and the parent's
TracePoint hook is bound to the dead scheduler. Without an after_fork
reset, the first attempt to acquire a symdb mutex in the child can
deadlock on an orphan lock, and a force_upload-mode child never picks
up where the parent left off.

`Component#after_fork!` reinitializes:

- Hot-load: buffer cleared, `@initial_extraction_done = false`,
  `@hot_load_tracepoint = nil`. The next `start_upload` installs a
  fresh TracePoint bound to the child's component and triggers its own
  initial extraction.
- Scheduler: thread/`@scheduled_at`/`@scheduler_signaled` cleared;
  `@scheduler_mutex` and `@scheduler_cv` reinitialized.
- Upload: `@upload_in_progress = false`; `@mutex`,
  `@upload_in_progress_cv`, `@last_upload_time_cv`,
  `@hot_load_buffer_mutex` reinitialized.
- Force-upload mode: re-registers the deferred-upload callback in the
  child. In Rails, `:after_initialize` already fired in the parent,
  so the on_load block runs immediately and the child schedules its
  own upload.

Cross-process upload deduplication is deliberately out of scope:
each forked Component performs its own initial extraction. Workers
in `preload_app! + eager_load=true` deployments hold identical code
to the parent — backend content dedup is tracked separately in
`projects/symdb/backlog/impl.md §Fork/child dedup` and
`projects/symdb/design/fork-architecture.md`.

Wired from `Core::Configuration::Components#after_fork` alongside
telemetry/remote/crashtracker/ProcessDiscovery.

Unit specs cover: mutex/CV reinit, scheduler thread/state reset,
hot-load buffer/flag/tracepoint reset, `@upload_in_progress`
reset, force-upload re-trigger, and that start_upload still works
after after_fork!.

Local rspec couldn't run (libdatadog 33.0.0.1.0 not installed in
this dev env) — CI is the source of truth.

The previous Steep fix in 51f692a removed two `# steep:ignore
NoMethod` directives in remote.rb because Steep flagged them as
redundant. But the redundancy was a symptom — the underlying cause was
in `sig/datadog/symbol_database/remote.rbs`, where commit e002f60
weakened `change` and `changes` parameters to `untyped` to bypass union
narrowing issues. With `change: untyped`, `change.content` type-checks
trivially, which made the genuine NoMethod-suppressing ignores look
redundant.

Restore the proper types on remote.rbs (matching master and DI):

- `receiver` block param: `Array[untyped]` →
  `Array[Datadog::Core::Remote::Configuration::Repository::change]`
- `process_change` change param: `untyped` →
  `Datadog::Core::Remote::Configuration::Repository::change`

The `case change.type` body in process_change already uses
`# @type var change: ...Inserted/Updated/Deleted` to narrow within each
when branch. The `else` and `rescue` branches operate on the un-narrowed
union, so reinstate the `# steep:ignore NoMethod` directives there —
they suppress real errors, not redundant ones.

Verification: `bundle exec rake typecheck` clean.

Co-Authored-By: Claude <[email protected]>

… state

Code (lib/datadog/symbol_database/component.rb):
- stop_upload: disable @hot_load_tracepoint, clear @hot_load_buffer, reset
  @initial_extraction_done. Without this, post-disable class loads kept
  re-arming the scheduler via enqueue_hot_load — RC could "stop" symdb
  but extraction continued every time a class loaded.
- after_fork!: @hot_load_tracepoint&.disable before niling the ivar. In a
  preloaded forking server, fork copies the parent's enabled TracePoint
  into the child where it stays rooted by the VM. Without an explicit
  disable, the child held two enabled TracePoints after the next
  start_upload: the inherited one (now unreferenced and unmanageable)
  plus the freshly installed one. shutdown! could only reach the new
  one.
- after_fork! docstring no longer references an internal-only path.

Specs (spec/datadog/symbol_database/component_spec.rb):
- Add: stop_upload disables the TracePoint, clears the buffer, resets the
  initial-extraction flag, and prevents a post-stop class definition
  from triggering extraction.
- Add: after_fork! disables the inherited TracePoint before clearing
  the reference.
- Rewrite 'does not extract again after start, stop, re-start' as
  're-runs extract_all after stop_upload + start_upload'. With
  @initial_extraction_done reset by stop_upload, a subsequent
  start_upload models RC re-enable and runs a fresh extract_all.
- Delete 'short-circuits when the process has already uploaded' — it
  called the removed mark_uploaded class method and would raise
  NoMethodError at runtime.
- Delete the duplicate stale debounce-named example that still asserted
  eq(1) under the rebuild-then-start sequence — the actual debounce
  property is covered earlier in the file, and 'each Component built
  across reconfigurations extracts independently' covers the new
  per-Component model.

Integration spec (spec/datadog/symbol_database/remote_config_integration_spec.rb):
- Rewrite 'a second start_upload with no new class loads' to omit
  stop_upload between calls. With the new stop_upload semantics, the
  prior shape (start, stop, start) would now extract twice; the
  property the test cares about — empty hot-load drain produces no
  upload — is verified by back-to-back start_upload calls.

Type signatures (sig/datadog/symbol_database/component.rbs):
- Remove stale class-level dedup declarations: @uploaded_this_process,
  @upload_done_mutex, @upload_done_cv, and the four class methods —
  none exist in the implementation any more.
- Restore @logger, initialize logger param, and environment_supported?
  logger param to SymbolDatabase::Logger. Steep is clean with the
  tighter type; the earlier 'untyped' revert was based on a wrong
  reading of the Uploader sig (uploader.rbs already declares
  SymbolDatabase::Logger).

Addresses chatgpt-codex-connector and Copilot review comments on
PR #5697.

Verification: bundle exec rspec spec/datadog/symbol_database/component_spec.rb
→ 42 examples, 0 failures. bundle exec steep check sig/datadog/symbol_database
lib/datadog/symbol_database → clean.

Co-Authored-By: Claude <[email protected]>

…eduped

Address review comment from chatgpt-codex-connector:
`@scope_batcher` was the one piece of fork-affected state that
`after_fork!` left inherited. `ScopeBatcher#add_scope`
(`lib/datadog/symbol_database/scope_batcher.rb:89`) skips any scope
whose name is already in `@uploaded_modules`. A child re-extracting
under `preload_app!` therefore dropped every scope name the parent had
already uploaded — silently, with no log line — and the child's
extract_all produced an empty upload.

- Replaced `@scope_batcher` with a fresh `ScopeBatcher` instance in
  `lib/datadog/symbol_database/component.rb#after_fork!`, alongside the
  other fork-local reinit. Also gives the child a fresh batcher mutex
  and timer-thread reference.
- Extended the `after_fork!` doc comment to list the batcher with the
  other recreated state and explain the dedup-set hazard.
- Added a spec in `spec/datadog/symbol_database/component_spec.rb` that
  verifies `after_fork!` replaces `@scope_batcher` with a fresh
  instance.

Verified: spec/datadog/symbol_database/ (348 examples, 0 failures);
Steep clean; StandardRB clean.

Co-Authored-By: Claude Opus 4.7 <[email protected]>

Address two Copilot review comments on the same race pattern:
`stop_upload` (lines 215-216) and `shutdown!` (lines 255-256) both
mutated `@hot_load_tracepoint` outside `@scheduler_mutex`, while
`start_upload#install_hot_load_hook` installs/enables it inside the
mutex. The leaking interleaving:

1. T1 (stop_upload or shutdown!) reads `@hot_load_tracepoint` as nil
   or disabled.
2. T2 (start_upload) acquires `@scheduler_mutex`, installs and enables
   a fresh TracePoint, exits the mutex.
3. T1's `@hot_load_tracepoint = nil` clears the reference, but the
   newly enabled TracePoint stays rooted by the VM.

For `stop_upload`, the leaked TracePoint keeps re-scheduling uploads
after RC disabled symdb. For `shutdown!`, `enqueue_hot_load`'s
`return if @shutdown` skips re-scheduling but only after the buffer
push — `@hot_load_buffer` grows unbounded for the rest of the process
lifetime.

- Moved `@hot_load_tracepoint&.disable; @hot_load_tracepoint = nil`
  inside the existing `@scheduler_mutex.synchronize` block in both
  methods, so the TracePoint teardown is atomic with the scheduler
  state mutation against a concurrent `start_upload`.
- Updated the doc comments on both methods to state the locking
  discipline.
- Added a regression test verifying a class load after `shutdown!`
  does not enqueue into the hot-load buffer (parallel to the existing
  post-`stop_upload` coverage).

`after_fork!` also mutates `@hot_load_tracepoint` outside the mutex,
but only the calling thread is alive in the child (fork invariant),
so there is no race — left as-is.

Verified: spec/datadog/symbol_database/ (348 examples, 0 failures);
Steep clean; StandardRB clean.

Co-Authored-By: Claude Opus 4.7 <[email protected]>

Steep CI failed with `Cannot find the declaration of constant:
MODULE_SINGLETON_CLASS_PRED` at lib/datadog/symbol_database/component.rb:54
and :545 — the constant was added in 1fc608e to harden the hot-load
TracePoint against user `singleton_class?` overrides, but the matching
RBS declaration was not added.

- Added `MODULE_SINGLETON_CLASS_PRED: ::UnboundMethod` next to the
  existing `EXTRACT_DEBOUNCE_INTERVAL` declaration in
  sig/datadog/symbol_database/component.rbs, mirroring the
  Extractor::MODULE_SINGLETON_CLASS_PRED declaration in
  sig/datadog/symbol_database/extractor.rbs.

Verified locally: `bundle exec steep check` clean;
`bundle exec rspec spec/datadog/symbol_database/` 348 examples 0 failures;
`bundle exec rake standard` clean.

Co-Authored-By: Claude Opus 4.7 <[email protected]>

Five-step verification of the hot-load hook in the existing
remote_config_integration_spec — initial upload runs, asserts the
runtime-defined class is not in the initial payload, defines the class
via 'load' so source_location passes user_code_path?, waits for the
debounced second upload event-driven via 'wait_for_idle' (no sleep),
asserts the class is present in the second upload's gunzipped payload.

Complements the existing component_spec hot-load coverage test which
mocks Extractor#extract — this test exercises the full tracer flow
through the transport boundary.

Test was measured at ~0.25s locally; 30s was cargo-culted from
surrounding tests in the same file. 5s gives ~20x headroom over
measured runtime while letting a broken signal fail in seconds
instead of a half-minute. Added a code comment recording the
measurement.